Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC

[Fred Baker <[e-mail]>]

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]