strict and loose uRPF. Sanity check please.

[George Jones <gmj@pobox.com>]

I'm going slow with changes until I get feedback from the IESG, but it
was pointed out that the draft required strict but not loose uRPF and
that loose RPF is actualy more useful in the NSP/large network
context.  To that end, I've reworked a few things.

Sanity check ?

new>   Bogon.
new>
new>      A "Bogon" (plural: "bogons") is an IP address in an address block
new>      not yet allocated by IANA or the Regional Internet Registries
new>      (ARIN, RIPE, APNIC...) as well as all addresses reserved for
new>      private or special use by RFCs.   See [RFC3330] and [RFC1918].
new>
new>
new>   Martian.
new>
new>      Per [RFC1208] "Martian: Humorous term applied to packets that turn
new>      up unexpectedly on the wrong network because of bogus routing
new>      entries.  Also used as a name for a packet which has an altogether
new>      bogus (non-registered or ill-formed) Internet address."  For the
new>      purposes of this document Martians are defined as "packets having
new>      a source address that, by application of the current forwarding
new>      tables, would not have its return traffic routed back to the
new>      sender."  "Spoofed packets" are a common source of martians.
new>
updated>   Spoofed Packet.
updated>
updated>      A "spoofed packet" is defined as a packet that has a source
updated>      address that does not correspond to any address assigned to the
updated>      system which sent the packet.  Spoofed packets are often "bogons"
updated>      or "martians".
updated>
updated>2.5.6 Support Automatic Anti-spoofing for Single-Homed Networks
updated>
updated>   Requirement.
updated>
updated>      The device MUST provide a means to designate particular interfaces
updated>      as servicing "single-homed networks" (see Section 1.8) and MUST
updated>      provide an option to automatically drop "spoofed packets" (Section
updated>      1.8) received on such interfaces where application of the current
updated>      forwarding table would not route return traffic back through the
updated>      same interface. This option MUST work in the presence of dynamic
updated>      routing and dynamically assigned addresses.
updated>
updated>   Justification. See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8
updated>      of [RFC1812], and [RFC2867].
updated>
updated>   Examples.
updated>
updated>      This requirement could be satisfied in several ways.  It could be
updated>      satisfied by the provision of a single command that automatically
updated>      generates and applies filters to an interface that implements
updated>      anti-spoofing.   It could be satisfied by the provision of a
updated>      command that causes the return path for packets received to be
updated>      checked against the current forwarding tables and dropped if they
updated>      would not be forwarded back through the interface on which they
updated>      were received.
updated>
updated>      See strict Unicast Reverse Path Forwarding (uRPF) in Cisco IOS and
updated>      unicast reverse path with "active-paths" for Juniper.
updated>
updated>   Warnings. None.
new>
new>
new>2.5.7 Support Automatic Discarding Of Bogons and Martians
new>
new>   Requirement.
new>
new>      The device MUST provide a means to automatically drop all "bogons"
new>      (Section 1.8) and "martians" (Section 1.8). This option MUST work
new>      in the presence of dynamic routing and dynamically assigned
new>      addresses.
new>
new>   Justification.
new>
new>      These sorts of packets have little (no?) legitimate use and are
new>      used primarily to allow individuals and organization to avoid
new>      identification (and thus accountability) and appear to be most
new>      often used for DoS attacks, email abuse, hacking, etc. In
new>      addition, transiting these packets needlessly consumes resources
new>      and may lead to capacity and performance problems for customers.
new>
new>      See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
new>      [RFC1812], and [RFC2867].
new>
new>   Examples.
new>
new>      This requirement could be satisfied by the provision of a command
new>      that causes the return path for packets received to be checked
new>      against the current forwarding tables and dropped if no viable
new>      return path exists. This assumes that steps are taken to assure
new>      that no bogon entries are present in the forwarding tables (for
new>      example filtering routing updates per Section 2.7.5 to reject
new>      advertisements of unassigned addresses).
new>
new>      See loose Unicast Reverse Path Forwarding (uRPF) in Cisco IOS and
new>      unicast reverse path with "feasible-paths" for Juniper.
new>
new>   Warnings. None.
new>
updated>
updated>2.5.8 Support Counters For Packets Dropped
updated>
updated>   Requirement.
updated>
updated>      The device MUST provide accurate, per-interface counts of spoofed
updated>      packets dropped in accordance with Section 2.5.6 and Section
updated>      2.5.7.
updated>