[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC
On Apr 16, 2009, at 7:27 PM, Brian E Carpenter wrote:
It pains me to say it, but I think the following sentence in the
Overview section should simply be deleted:
"It should be noted that NAT for IPv6 is both strictly forbidden by
the standards documents and strongly deprecated by Internet
operators."
It is also untrue. The operators are not asking for NAT to go away. In
fact, many enterprise administrations including Apple's and Cisco's
are finding places where they specifically want to use NAT technology.
"2.1. Basic Sanitation
In addition to the functions required of all Internet routers
[RFC4294], residential gateways are expected to have basic stateless
filters for prohibiting certains kinds of traffic with invalid
headers, e.g. martian packets, spoofs, routing header type code
zero,
etc."
I think 'martian' needs a definition.
Maybe you want to pick one of the following? I would go for the
discussion in RFC 1208, or the one in RFC 1812.
http://www.ietf.org/rfc/rfc1208.txt
1208 A Glossary of Networking Terms. O.J. Jacobsen, D.C. Lynch. March
1991. (Format: TXT=41156 bytes) (Status: INFORMATIONAL)
Martian: Humorous term applied to packets that turn up unexpectedly
on the wrong network because of bogus routing entries. Also used as
a name for a packet which has an altogether bogus (non-registered or
ill-formed) Internet address.
http://www.ietf.org/rfc/rfc1542.txt
1542 Clarifications and Extensions for the Bootstrap Protocol. W.
Wimer. October 1993. (Format: TXT=52948 bytes) (Obsoletes RFC1532)
(Updates RFC0951) (Status: DRAFT STANDARD)
Hosts and routers are usually required to silently discard incoming
datagrams containing illegal IP source addresses. This is generally
known as "Martian address filtering." One of these illegal
addresses
is 0.0.0.0 (or actually anything on network 0). However, hosts or
routers which support a BOOTP relay agent MUST accept for local
delivery to the relay agent BOOTREQUEST messages whose IP source
address is 0.0.0.0. BOOTREQUEST messages from legal IP source
addresses MUST also be accepted.
http://www.ietf.org/rfc/rfc1812.txt
1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated
by
RFC2644) (Status: PROPOSED STANDARD)
5.3.7 Martian Address Filtering
Martian Filtering
A packet that contains an invalid source or destination address
is considered to be martian and discarded.
http://www.ietf.org/rfc/rfc2650.txt
2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M.
Prior, C. Alaettinoglu. August 1999. (Format: TXT=55272 bytes)
(Status: INFORMATIONAL)
Figure 18 presents some example route-set objects. The set rs-uo
contains two address prefixes, namely 128.223.0.0/16 and
198.32.162.0/24. The set rs-bar contains the members of the set rs-
uo and the address prefix 128.7.0.0/16. The set rs-martians
illustrate the use of range operators. 0.0.0.0/0^32 are the length
32 more specifics of 0.0.0.0/0, i.e. the host routes; 224.0.0.0/3^+
are the more specifics of 224.0.0.0/3, i.e. the routes falling into
the multicast address space. For more complete list of range
operators please refer to RFC-2622.
route-set: rs-martians
remarks: routes not accepted from any peer
members: 0.0.0.0/0, # default route
0.0.0.0/0^32, # host routes
224.0.0.0/3^+, # multicast routes
127.0.0.0/8^9-32, . . .
As part of the decapsulation the node SHOULD silently discard a
packet with an invalid IPv4 source address such as a multicast
address, a broadcast address, 0.0.0.0, and 127.0.0.1. In general it
SHOULD apply the rules for martian filtering in [18] and ingress
filtering [13] on the IPv4 source address.
After the decapsulation the node SHOULD silently discard a packet
with an invalid IPv6 source address. This includes IPv6 multicast
addresses, the unspecified address, and the loopback address but
also
IPv4-compatible IPv6 source addresses where the IPv4 part of the
address is an (IPv4) multicast address, broadcast address, 0.0.0.0,
or 127.0.0.1. In general it SHOULD apply the rules for martian
filtering in [18] and ingress filtering [13] on the IPv4-compatible
source address.
http://www.ietf.org/rfc/rfc3704.txt
3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
BCP0084) (Status: BEST CURRENT PRACTICE)
RFC 2827 recommends that ISPs police their customers' traffic by
dropping traffic entering their networks that is coming from a
source
address not legitimately in use by the customer network. The
filtering includes but is in no way limited to the traffic whose
source address is a so-called "Martian Address" - an address that is
reserved [3], including any address within 0.0.0.0/8, 10.0.0.0/8,
127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, or
240.0.0.0/4.
The questionable benefit of Loose RPF is found in asymmetric routing
situations: a packet is dropped if there is no route at all, such as
to "Martian addresses" or addresses that are not currently routed,
but is not dropped if a route exists.
One case where Loose RPF might fit well could be an ISP filtering
packets from its upstream providers, to get rid of packets with
"Martian" or other non-routed addresses.
If other approaches are unsuitable, loose RPF could be used as a
form
of contract verification: the other network is presumably certifying
that it has provided appropriate ingress filtering rules, so the
network doing the filtering need only verify the fact and react if
any packets which would show a breach in the contract are detected.
Of course, this mechanism would only show if the source addresses
used are "martian" or other unrouted addresses -- not if they are
from someone else's address space.
Therefore, the use of Loose RPF cannot be recommended, except as a
way to measure whether "martian" or other unrouted addresses are
being used.
o Loose RPF primarily filters out unrouted prefixes such as Martian
addresses. It can be applied in the upstream interfaces to
reduce
the size of DoS attacks with unrouted source addresses. In the
downstream interfaces it can only be used as a contract
verification, that the other network has performed at least some
ingress filtering.
http://www.ietf.org/rfc/rfc3871.txt
3871 Operational Security Requirements for Large Internet Service
Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September
2004. (Format: TXT=151101 bytes) (Status: INFORMATIONAL)
Per [RFC1208] "Martian: Humorous term applied to packets that
turn
up unexpectedly on the wrong network because of bogus routing
entries. Also used as a name for a packet which has an
altogether
bogus (non-registered or ill-formed) Internet address." For the
purposes of this document Martians are defined as "packets having
a source address that, by application of the current forwarding
tables, would not have its return traffic routed back to the
sender." "Spoofed packets" are a common source of martians.
A "spoofed packet" is defined as a packet that has a source
address that does not correspond to any address assigned to the
system which sent the packet. Spoofed packets are often "bogons"
or "martians".
2.5.6. Support Automatic Discarding Of Bogons and Martians
The device MUST provide a means to automatically drop all
"bogons"
(Section 1.8) and "martians" (Section 1.8). This option MUST
work
in the presence of dynamic routing and dynamically assigned
addresses.
o Support Automatic Discarding Of Bogons and Martians
http://www.ietf.org/rfc/rfc3964.txt
3964 Security Considerations for 6to4. P. Savola, C. Patel. December
2004. (Format: TXT=83360 bytes) (Status: INFORMATIONAL)
Alexey Kuznetsov brought up the implementation problem with IPv6
martian checks. Christian Huitema formulated the rules that rely on
6to4 relays using only anycast. Keith Moore brought up the point
about reduced flexibility. Brian Carpenter, Tony Hain, and
Vladislav
Yasevich are acknowledged for lengthy discussions. Alain Durand
reminded the authors about relay spoofing problems. Brian Carpenter
reminded the authors about the BGP-based 6to4 router model.
Christian Huitema gave a push for a more complete threat analysis.
Itojun Hagino spelled out the operators' fears about 6to4 relay
http://www.ietf.org/rfc/rfc4276.txt
4276 BGP-4 Implementation Report. S. Hares, A. Retana. January 2006.
(Format: TXT=132864 bytes) (Status: INFORMATIONAL)
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N Ignores the prefix in case of
martian nexthop, and in case of
length not equal to IPv4
address-length, we send
NOTIFICATION with error subcode
Attribute Length error.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
http://www.ietf.org/rfc/rfc4379.txt
4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures. K. Kompella, G. Swallow. February 2006. (Format:
TXT=116872
bytes) (Updates RFC1122) (Updated by RFC5462) (Status: PROPOSED
STANDARD)
Although this document makes special use of 127/8 address, these are
used only in conjunction with the UDP port 3503. Furthermore, these
packets are only processed by routers. All other hosts MUST treat
all packets with a destination address in the range 127/8 in
accordance to RFC 1122. Any packet received by a router with a
destination address in the range 127/8 without a destination UDP
port
of 3503 MUST be treated in accordance to RFC 1812. In particular,
the default behavior is to treat packets destined to a 127/8 address
as "martians".
http://www.ietf.org/rfc/rfc4949.txt
4949 Internet Security Glossary, Version 2. R. Shirey. August 2007.
(Format: TXT=867626 bytes) (Obsoletes RFC2828) (Also FYI0036)
(Status: INFORMATIONAL)
$ Martian
(D) /slang/ A packet that arrives unexpectedly at the wrong
address or on the wrong network because of incorrect routing or
because it has a non-registered or ill-formed IP address. [R1208]