[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-savi-threat-scope

INTERNET-DRAFT                               Danny McPherson
                                              Arbor Networks
                                                  Fred Baker
                                               Cisco Systems
Expires: September 2008                       March 13, 2008
Intended Status: Informational

                           SAVI Threat Scope

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The IETF Trust (2008).

McPherson, Baker                                                [Page 1]

INTERNET-DRAFT           Expires: September 2008              March 2008


   This memo discusses threats enabled by IP source address spoofing and
   discusses a number of techniques aimed at mitigating those threats.

McPherson, Baker                                                [Page 2]

INTERNET-DRAFT           Expires: September 2008              March 2008

Table of Contents

   1. Specification of Requirements. . . . . . . . . . . . . . . . .   5
   2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3. Glossary of Terms. . . . . . . . . . . . . . . . . . . . . . .   6
   4. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . .   7
    4.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.1. Single Packet DoS. . . . . . . . . . . . . . . . . . . .   7
     4.1.2. Flood-Based DoS. . . . . . . . . . . . . . . . . . . . .   8
     4.1.3. Poisoning Attacks. . . . . . . . . . . . . . . . . . . .   8
     4.1.4. Third Party Recon. . . . . . . . . . . . . . . . . . . .   9
     4.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . .   9
     4.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . .   9
     4.1.7. Accounting Subversion. . . . . . . . . . . . . . . . . .  10
     4.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . .  10
    4.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . .  10
     4.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . .  10
     4.2.2. Third Party Recon. . . . . . . . . . . . . . . . . . . .  11
   5. Current Anti-Spoofing Solutions. . . . . . . . . . . . . . . .  11
    5.1. Host to link layer neighbor or switch . . . . . . . . . . .  13
    5.2. Upstream routers. . . . . . . . . . . . . . . . . . . . . .  13
    5.3. ISP edge PE Router. . . . . . . . . . . . . . . . . . . . .  14
    5.4. ISP NNI Router to ISP NNI Router. . . . . . . . . . . . . .  14
    5.5. Spoofing In Local Area Network Segments . . . . . . . . . .  14
    5.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . .  15
    5.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . .  15
    5.8. BCP 38. . . . . . . . . . . . . . . . . . . . . . . . . . .  15
    5.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . .  15
    5.10. Port-based Address Binding . . . . . . . . . . . . . . . .  15
     5.10.1. Manual Binding. . . . . . . . . . . . . . . . . . . . .  16
     5.10.2. Automated Binding . . . . . . . . . . . . . . . . . . .  16
     5.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . .  16
    5.11. Cryptographic Techniques . . . . . . . . . . . . . . . . .  16
    5.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . .  17
   6. Topological Considerations . . . . . . . . . . . . . . . . . .  17
    6.1. Address Provisioning Mechanisms . . . . . . . . . . . . . .  17
    6.2. LAN devices with Multiple Addresses . . . . . . . . . . . .  17
     6.2.1. Routers. . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . .  18
     6.2.4. Multi-LAN Hosts. . . . . . . . . . . . . . . . . . . . .  18
     6.2.5. Firewalls. . . . . . . . . . . . . . . . . . . . . . . .  19
     6.2.6. Mobile IP. . . . . . . . . . . . . . . . . . . . . . . .  19
     6.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . .  19
   7. Applicability of Anti-Spoofing Solutions . . . . . . . . . . .  19
    7.1. Analysis of Host Granularity Anti-Spoofing. . . . . . . . .  19

McPherson, Baker                                                [Page 3]

INTERNET-DRAFT           Expires: September 2008              March 2008

   8. Deployment Considerations. . . . . . . . . . . . . . . . . . .  20
   9. Security Considerations. . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
   12. References. . . . . . . . . . . . . . . . . . . . . . . . . .  23
    12.1. Normative References . . . . . . . . . . . . . . . . . . .  23
    12.2. Informative References . . . . . . . . . . . . . . . . . .  23
   13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  24

McPherson, Baker                                                [Page 4]

INTERNET-DRAFT           Expires: September 2008              March 2008

1.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC 2119].

2.  Overview

   The Internet Protocol, specifically IPv4 [RFC 791] and IPv6 [RFC
   2460], employ a connectionless hop-by-hop packet forwarding paradigm.
   A host connected to an IP network that wishes to communicate with
   another host on the network generates an IP packet with source and
   destination IP addressing information, among other options.

   At the IP Network Layer, or Internet Layer, there is typically no
   required transactional state when communicating with other hosts on
   the network.  Hosts generating packets for transmission have the
   opportunity to spoof (forge) the source address of packets which they

   Source address verification is necessary in order to detect and
   reject spoofed packets and contribute to the overall security of IP
   networks.  In particular, source address verification techniques
   enable detection and rejection of spoofed packets, and also
   implicitly provide some assurances that the source address in an IP
   packet is legitimately assigned to the system that generated the

   Solutions such as BCP 38 [RFC 2827] provide guidelines for one such
   technique for network ingress filtering.  However, if these
   techniques are not implemented on 32-bit prefix boundaries at the
   ultimate ingress point of the IP network then the validity of the
   source address can not be positively ascertained.  Furthermore, BCP
   38 only implies source address verification at the Internet Layer,
   and is most often implemented on IP subnetwork address boundaries.

   There is a possibility that in an LAN environment where multiple
   hosts share a single IP port on a switch or router, one of those
   hosts may source address spoof the source addresses of other hosts
   within the local subnet.  Understanding these threats and the
   relevant topologies in which they're introduced is critical when
   assessing the threats that exists with source address spoofing.

   The aim of this document is to provide some additional details

McPherson, Baker                                    Section 2.  [Page 5]

INTERNET-DRAFT           Expires: September 2008              March 2008

   regarding spoofed-based threat vectors, and discuss implications of
   various network topologies.

3.  Glossary of Terms

   The following acronyms and terms are used throughout this memo.

   BGP:  The Border Gateway Protocol, used to manage routing policy
      between large networks.

   CPE Router:  Customer Premises Equipment Router.  The router on the
      customer premises, whether owned by the customer or the provider.
      Also called the Customer Endpoint, or CE, Router.

   IP Address:  An Internet Protocol Address, whether IPv4 or IPv6.

   ISP:  Internet Service Provider.  Any person or company that delivers
      Internet service to another.

   MAC Address:  An Ethernet Address.

   NNI Router:  Network to Network Interface Router.  This router
      interface faces a similar system operated by another ISP or other
      large network.

   PE Router:  Provider Endpoint Router.  This router faces a customer
      of an ISP.

   Spoofing: The act of forging datagram header contents at the Link
      or Network Layer

   TCP:  The Transmission Control Protocol, used on end systems to
      manage data exchange.

   uRPF:  Unicast Reverse Path Forwarding.  A procedure in which the
      route table, which is usually used to look up destination
      addresses and route towards them, is used to look up the source
      address and ensure that one is routing away from it.  When this
      test fails, the event may be logged, and the traffic is commonly

McPherson, Baker                                    Section 3.  [Page 6]

INTERNET-DRAFT           Expires: September 2008              March 2008

4.  Spoofed-based Attack Vectors

   Spoofing is employed on the Internet for a number of reasons, most of
   which are in some manner associated with malicious or otherwise
   nefarious activities.  In general, two classes of spoofed-based
   attack vectors exists; blind attacks and non-blind attacks.  The
   follow sections provide some information of blind and non-blind

4.1.  Blind Attacks

   Blind attacks typically occur when an attacker isn't on the same
   local area network as a source or target, or when an attacker has no
   access to the datapath between the attack source(s) and the target
   systems.  The result is that they have no access to legitimate source
   and target systems.

4.1.1.  Single Packet DoS

   One type of blind attacks, which we'll refer to here as "single
   packet DoS attacks", involves an attacking system injecting spoofed
   information into the network which results in either a complete crash
   of the target system, or in some manner poisons some network
   configuration or other information on a target system such to impact
   network or other services.

   An example of an attack that can cause a receiving system to crash is
   a LAND attack.  A LAND attack packet would consist of an attacking
   system forwarding a packet (e.g., TCP SYN) to a target system that
   contains both a source and destination address of that target system.
   The target system would "lock up" when creating connection state
   associated with the packet, or would get stuck in a state where it
   continuously replies to itself.

   Another example of a single packet DoS attack involves that of a
   system poisoning network or DNS cache information, perhaps in order
   to simply break a given hosts connection, enable MITM or other
   attacks.  Network level attacks that could involve single packet DoS
   include ARP cache poisoning and ICMP redirects.

McPherson, Baker                                Section 4.1.1.  [Page 7]

INTERNET-DRAFT           Expires: September 2008              March 2008

4.1.2.  Flood-Based DoS

   Flooding-based DoS attack vectors are particularly effective attacks
   on the Internet today.  They usually entail flooding a large number
   of packets towards a target system, with the hopes of either
   exhausting connection state on the target system, consuming all
   packet processing capabilities of the target or intermediate systems,
   or consuming a great deal of bandwidth available to the target system
   such that they are essentially inaccessible.

   Because these attacks require no reply from the target system and
   require no legitimate transaction state, attackers often attempt to
   obfuscate the identity of the systems that are generating the attack
   traffic by spoofing the source IP address of the attacking traffic
   flows.  Because ingress filtering isn't applied ubiquitously on the
   Internet today, spoof-based flooding attack vectors are typically
   very difficult to traceback.  In particular, there may be one or more
   attacking sources beyond your network border, and the attacking
   sources may or may not be legitimate sources, it's difficult to
   discriminate if the sources are not directly connected to the local
   routing system.

   Common flood-based DoS attack vectors today include SYN floods, ICMP
   floods, and IP fragmentation attacks.  Attackers may use a single
   legitimate or spoofed fixed attacking source addresses, although
   frequently they cycle through large swaths of address space.  As a
   result, mitigating these attacks  on the receiving end with source-
   based policies is extremely difficult.

   Furthermore, the motivator for spoof-based DoS attacks may actually
   be to encourage the target to filter explicitly on a given set of
   source addresses, or order to disrupt the legitimate owner(s) access
   to the target system.

4.1.3.  Poisoning Attacks

   As discussed in single-packet DoS above, there are several other
   attack mechanisms that employ source address spoofing.  The more
   common of these attack vectors include DNS cache poisoning, ARP cache
   poisoning, and ICMP redirects.  While these attacks can be used for
   disrupting services, they're often used to redirect traffic to
   network elements where attack intends to carry out additional
   malicious activities.

McPherson, Baker                                Section 4.1.3.  [Page 8]

INTERNET-DRAFT           Expires: September 2008              March 2008

4.1.4.  Third Party Recon

   Third party reconnaissance attacks may be either blind or non-blind
   attacks.  An example of third party reconnaissance is when an
   attacker wishes to fingerprint a remote operating system type,
   perhaps in order to initiate some TCP session hijacking, and in order
   to do so must be able to identify the TCP sequence and algorithm
   employed by the target system.  Initiating a determined number of
   connections with the target system may assist with this.

4.1.5.  Spoof-based Worm/Malware Propagation

   Self-propagating malware has been observed that spoofs it's source
   address when attempting to propagate to other systems.  Presumably,
   this was done to obfuscate the actual source address of the infected

4.1.6.  Reflective Attacks

   DNS reflective amplification attacks are a particularly potent DoS
   attack vector on the Internet today.  Like other amplification
   attacks, an attack source generates a packet with a source-spoofed
   address mapping to that of the target system.  The packet, upon
   receipt by the victim or some intermediate node, typically illicts a
   large reply message, which is directed to the target of the attack.
   The amplification factor observed for attacks targeting DNS root and
   other top level domain name infrastructure in early 2006 was on the
   order of 76:1.  The result is that just 15 attacking sources with
   512k of upstream attack bandwidth could generate one Gbps of response
   attack traffic towards a target system.

   Smurf attacks employ a similar reflective amplification attack
   vector, exploiting traditional default IP subnet directed broadcast
   address behaviors that would result in all the active hosts on a
   given subnet responding to (spoofed) ICMP echo request from an
   attacker, and generating a large amount of ICMP echo response traffic
   directed towards a target system.  They were particularly effective
   in large campus LAN environments where 50k or more hosts might reside
   on a single subnet.

McPherson, Baker                                Section 4.1.6.  [Page 9]

INTERNET-DRAFT           Expires: September 2008              March 2008

4.1.7.  Accounting Subversion

   If an attacker wishes to distribute content or other material in a
   manner that employs protocols that require only uni-directional
   flooding and generate no end-end transactional state, they may desire
   to spoof the source IP address of that content in order to avoid
   detection or accounting functions enabled at the IP layer.

4.1.8.  Other Blind Spoofing Attacks

   Other Blind spoofing attacks might include spoofing in order to
   exploit source routing or other policy based routing implemented in a

4.2.  Non-Blind Attacks

   Non-blind attacks often involve mechansisms such as eavesdropping on
   connection, resetting state so that new connections may be hijacking,
   and an array of other attack vectors.  Perhaps the most common of
   these attack vectors is known as man in the middle attacks.

4.2.1.  Man in the Middle (MITM)

   Connection Hijacking is one of the more common man in the middle
   attack vectors.  In order to hijack a connection an attacker usually
   needs to be in the forwarding path and often times employs TCP RST or
   other attacks in order to reset a transaction.  The attacker may have
   already compromised a system that's in the forwarding path, or they
   may which to insert themselves in the forwarding path.

   For example, an attacker with access to a host on LAN segment may
   wish to redirect all the traffic on the local segment destined for a
   default gateway address (or all addresses) to itself in order to
   perform man-in-the-middle attacks.  In order to accomplish this the
   attacker might transmit gratuitous ARP [ARP] messages or ARP replies
   to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, notifying all
   the hosts on the segment that the IP address(es) of the target(s) now
   map to it's own MAC address.  If the port to which the attacker is

McPherson, Baker                               Section 4.2.1.  [Page 10]

INTERNET-DRAFT           Expires: September 2008              March 2008

   connected were to implement policy that binds a single Link Layer and
   IP address tuple to that port upon initial provisioning, spoofed
   packets, at the Link Layer and/or Network Layer, would be discarded
   on ingress.

4.2.2.  Third Party Recon

   Another example of third party reconnaissance that falls into both
   the blind and non-blind attack class involves spoofing packets
   towards a given target system and observing either target or
   intermediate system responses.  For example, if an attacker were to
   source spoof TCP SYN packets towards a target system from a large set
   of source addresses, and observe responses from that target system or
   some intermediate firewall or other middle box, they would be able to
   identify what IP layer filtering policies may be in place to protect
   that system.

5.  Current Anti-Spoofing Solutions

   The first requirement is to eliminate datagrams with spoofed
   addresses from the Internet.  Identifying and dropping datagrams
   whose source address is incompatible with the Internet topology at
   sites where the relationship between the source address and topology
   can be checked can eliminate such datagrams.  For example, Internet
   devices can confirm that:

   o  The IP source address is appropriate for the lower layer address
      (they both identify the same system)

   o  The IP source address is appropriate for the device at the layer 2
      switch port (the address was assigned to a, and perhaps the,
      system that uses that port)

   o  The prefix to which the IP source address belongs is appropriate
      for the part of the network topology from which the IP datagram
      was received (while the individual system may be unknown, it is
      reasonable to believe that the system is located in that part of
      the network).

   Filtering points farther away from the source of the datagram can
   make decreasingly authoritative assertions about the validity of the
   source address in the datagram.  Nonetheless, there is value in

McPherson, Baker                                   Section 5.  [Page 11]

INTERNET-DRAFT           Expires: September 2008              March 2008

   dropping traffic that is clearly inappropriate, and in maintaining
   knowledge of the level of trust one can place in an address.

                   Edge Network 1            CPE-ISP _.------------.
                 _.----------------.         Ingress/   ISP A       `--.
            ,--''                   `---.      ,'                       `.
          ,'  +----+  +------+  +------+ `.   /  +------+       +------+  \
         (    |Host+--+Switch+--+ CPE  +---)-(---+  PE  +- - - -+ NNI  |   )
          `.  +----+  +------+  |Router| ,'   \  |Router|       |Router|  /
            `---. Host-neighbor +------+'      `.+------+       +--+---+,'
                 `----------------''             '--.              |_.-'
                   Edge Network 2                  ISP-ISP Ingress |
                 _.----------------.                  _.----------.|
            ,--''                   `---.         ,-''             |--.
          ,'  +----+  +------+  +------+ `.     ,+------+       +--+---+.
         (    |Host+--+Switch+--+ CPE  +---)---+-+  PE  +- - - -+ NNI  | \
          `.  +----+  +------+  |Router| ,'   (  |Router|       |Router|  )
            `---.               +------+'      \ +------+       +------+ /
                 `----------------''            `.                     ,'
                                                  '--.   ISP B     _.-'

           Figure 1: Points where an address can be validated

   Figure 1 illustrates five places where a source address can be

   o  Host to host or host to switch,

   o  Host to enterprise CPE Router,

   o  Enterprise CPE Router to ISP edge PE Router,

   o  ISP NNI Router to ISP NNI Router, and the

   o  ISP edge PE Router facing the destination CPE Router.

   In general, datagrams with spoofed addresses can be detected and
   discarded by devices that have an authoritative mapping between IP
   addresses and the network topology.  For example, a device that has

McPherson, Baker                                   Section 5.  [Page 12]

INTERNET-DRAFT           Expires: September 2008              March 2008

   an authoritative table between Link Layer and IP addresses on a link
   can discard any datagrams in which the IP address is not associated
   with the Link Layer address in the datagram.  The degree of
   confidence in the source address depends on where the spoofing
   detection is performed and the prefix aggregation in place between
   the spoofing detection and the source of the datagram.

5.1.  Host to link layer neighbor or switch

   The first point at which a datagram with a spoofed address can be
   detected is on the link to which the source of the datagram is
   connected.  At this point in the network, the source Link Layer and
   IP addresses are both available, and can be verified against each
   other.  A datagram in which the IP source address does not match the
   corresponding Link Layer address can be discarded.  Of course, the
   trust in the filtering depends on the trust in the method through
   which the mappings are developed.  This mechanism can be applied by
   neighboring hosts, or by the first hop router.

   On a shared medium link, such as Ethernet, the best that can be done
   is to verify the Link Layer and IP addresses against the mappings.
   When the link is not shared, such as when the hosts are connected
   through a switch, the source host can be identified precisely based
   on the port through which the datagram is received or the MAC address
   if it is known to the switch.  Port identification prevents
   transmission of malicious datagrams whose Link Layer and IP addresses
   are both spoofed to mimic another host.

5.2.  Upstream routers

   Beyond the first hop router, subsequent routers may additionally
   filter traffic from downstream networks.  Because these routers do
   not have access to the Link Layer address of the device from which
   the datagram was sent, they are limited to confirming that the source
   IP address is within a prefix that is appropriate for downstream
   router from which the datagram was received.

   Options include the use of simple access lists or the use of unicast
   reverse path filtering (uRPF).  Access lists are generally
   appropriate only for the simplest cases, as management can be
   difficult.  Strict Unicast RPF accepts the source address on a
   datagram if and only if it comes from a direction that would be

McPherson, Baker                                 Section 5.2.  [Page 13]

INTERNET-DRAFT           Expires: September 2008              March 2008

   rational to send a datagram directed to the address, which means that
   the filter is derived from routing information.  These filtering
   procedures are discussed in more detail in [RFC3704].

5.3.  ISP edge PE Router

   An obvious special case of the discussion is with an ISP PE router,
   where it provides its customer with access.  BCP 38 specifically
   encourages ISPs to use ingress filtering to limit the incidence of
   spoofed addresses in the network.

   The question that the ISP must answer for itself is the degree to
   which it trusts its downstream network. A contract might be written
   between an ISP and its customer requiring that the customer apply the
   procedures of network ingress filtering to the customer's own
   network, although there's no way upstream networks would be able to
   verify this.

5.4.  ISP NNI Router to ISP NNI Router

   The considerations explicitly related to customer networks can also
   be applied to neighboring ISPs.  An interconnection agreement might
   be written between two companies requiring network ingress filtering
   policy be implemented on all customers connections.  ISPs might, for
   example, mark datagrams from neighboring ISPs that do not sign such a
   contract or demonstrably do not behave in accordance with it as
   'untrusted'.  Alternatively, the ISP might place untrusted prefixes
   into a separate BGP community and use that to advertise the level of
   trust to its BGP peers.

   In this case, uRPF is less effective as a verification tool, due to
   asymmetric routing.  However, when it can be shown that spoofed
   addresses are present, the procedure can be applied.

5.5.  Spoofing In Local Area Network Segments

   On Link Layer segments where multiple hosts reside, or a single MAC
   address can be associated with a port or interface, if a binding
   between a hardware address (e.g., MAC address) and corresponding IP

McPherson, Baker                                 Section 5.5.  [Page 14]

INTERNET-DRAFT           Expires: September 2008              March 2008

   address(es) are not provisioned via some means (either manual or
   dynamic mechanisms), then an attacker may exploit attack vectors that
   enable MITM or other spoof-based attacks.

5.6.  Cable Modem Subscriber Access

   Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
   Control (MAC) domains, which are similar to Ethernet LAN

5.7.  DSL Subscriber Access

   Something about DSLAMs here..

5.8.  BCP 38

   If BCP 38 is implemented in LAN segments, it is typically done so on
   subnetwork boundaries and traditionally relates only to Network Layer
   ingress filtering policies.  The result is that hosts within the
   segment cannot spoof packets from address space outside of the local
   segment itself, however, they may still spoof packets using sources
   addresses that exist within the local network segment.

5.9.  Unicast RPF

   Unicast RPF is a crude mechanism to automate definition of BCP 38
   style filters based on routing table information.  It's applicability
   parallels that of BCP 38, although deployment caveats exists, as
   outlined in [BCP 84].

5.10.  Port-based Address Binding

   Much of the work SAVI appears to be initially targeting is aimed at

McPherson, Baker                                Section 5.10.  [Page 15]

INTERNET-DRAFT           Expires: September 2008              March 2008

   minimizing source address spoofing in the LAN.  In particular, if
   mechanisms can be defined to accommodate configuration of port
   binding information for IP and MAC layer addresses in LAN
   environments, a large portion of the spoofing threat space in the LAN
   can be marginalized.

   However, establishing these binding is not trivial, and varying
   across both topologies type and address allocation mechanisms.

5.10.1.  Manual Binding

   Binding of a single Link Layer and Network Layer address to a port
   may initially seem trivial.  However, two primary areas exist that
   can complicate such techniques.  In particular, these area involves
   topologies where more than a single IP layer address may be
   associated with a MAC address on a given port, or where multiple
   hosts are connected to a single IP port.  Furthermore, if one or more
   dynamic address allocation mechanisms such as DHCP are employed, then
   some mechanism must exist to associate those IP layer addresses with
   the appropriate Link layer ports, as addresses are allocated or

5.10.2.  Automated Binding

   DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc..

5.10.3.  IEEE 802.1X

5.11.  Cryptographic Techniques

   Needless to say, MITM and replay attacks can typically be mitigated
   with cryptographic techniques.  However, many of the applications
   today either don't or can't employ cryptographic authentication and
   protection mechanisms.  ARP and DNS are two examples.  DNSSEC does
   propose to assist, but until it's deployed ubiquitously, from
   clients, to resolvers, to authoritative roots, clients and resolvers

McPherson, Baker                                Section 5.11.  [Page 16]

INTERNET-DRAFT           Expires: September 2008              March 2008

   are still vulnerable to replay, cache poisoning and MITM attacks.

5.12.  Residual Attacks

   Stuff which these solutions don't address

   Stuff which no one will use the existing solutions for

6.  Topological Considerations

   As noted previously, topological components and address allocation
   mechanisms have significant implications on what is feasible with
   regard to Link layer address and IP address port bindings.  The
   following sections discuss some of the various topologies and address
   allocation mechanisms that proposed SAVI solutions should attempt to

6.1.  Address Provisioning Mechanisms

   In a strictly static environment configuration management for access
   filters that map Link Layer and Network Layer addresses on a specific
   switch port might be a viable option.  However, most networks,
   certainly, those that accommodate actual human users, are much more
   dynamic in nature.  As such, mechanisms that provide port-MAC-IP
   bindings need to accommodate dynamic address allocation schemes
   enabled by protocols such as DHCP.

6.2.  LAN devices with Multiple Addresses

   From a topology considerations perspective, when attempting port-MAC-
   IP bindings, host connected to switch ports that may have one or more
   IP addresses, or certainly, devices that forward packets from other
   network segments, are problematic.

McPherson, Baker                                 Section 6.2.  [Page 17]

INTERNET-DRAFT           Expires: September 2008              March 2008

6.2.1.  Routers

   The most obvious example of devices that are problematic when
   attempting to implement port-MAC-IP bindings is that of routers.
   Routers not only originate packets themselves and often have multiple
   interfaces, but also forward packets from other network segments.  As
   a result, it's difficult for port-MAC-IP binding rules to be
   established a priori, because it's likely that many addresses and IP
   subnets should be associated with the port-MAC in question.

6.2.2.  NATs

   Prefix-based and multi-address NATs also become problematic, for the
   same reasons as routers.  Because they may forward traffic from an
   array of address, a priori knowledge must exist providing what IPs
   should be associated with a given port-MAC pair.

6.2.3.  Multi-Instance Hosts

   Another example that introduces complexities is that of multi-
   instance hosts attached to a switch port.  Multi clients, with the
   same or different MACs, may be attached to the port and may either
   have static IP addresses assigned, or may receive one or more
   dynamically via DHCP or similar means.  Accommodating multi-instance
   hosts, or even blade-server type devices dynamic is feasible, buy may
   introduces complexities if the solution in question does not
   accommodate unique considerations introduced in these environments.

6.2.4.  Multi-LAN Hosts

   Multi-interface hosts, in particular those that are multi-homed and
   may forward packets from any of a number of source addresses, can be
   problematic as well.  In particular, if a port-MAC-IP binding is made
   on each of the interfaces, and then either a loopback IP or the
   address of third interface is used as the source address of a packet
   and forward through in interface for which the port-MAC-IP binding
   doesn't map, the traffic may be discarded.  Static configuration of
   port-MAC-IP bindings may accommodate this scenario, although some a

McPherson, Baker                               Section 6.2.4.  [Page 18]

INTERNET-DRAFT           Expires: September 2008              March 2008

   priori knowledge on address assignment and topology is required.

6.2.5.  Firewalls

   Firewalls that forward packets from other network segments, or serve
   as a source for locally originated packets, suffer from the same
   issues as routers.

6.2.6.  Mobile IP

   Need to say something here, I think...  Mobile IP

6.2.7.  Other Topologies

   Any topology that results in the possibility that a device connected
   to a switch port may forward packets with more than a single source
   address for packet which it originated may be problematic.
   Additionally, address allocation schemas introduce additional
   considerations when examining a given SAVI solutions space.

7.  Applicability of Anti-Spoofing Solutions

   What works where, what's needed?

   Ingress filtering is useful, even with botnets using real addresses

   Ingress filtering on the admin border is not sufficient, and more
   fine-grained filtering from savi is necessary.

7.1.  Analysis of Host Granularity Anti-Spoofing

   Most IP spoofing validation can be provided with standard IP-based
   policies such as those defined in BCP 38.  However, at the ultimate

McPherson, Baker                                 Section 7.1.  [Page 19]

INTERNET-DRAFT           Expires: September 2008              March 2008

   network ingress, the ability to perform a binding for port-MAC-IP
   provides considerable benefits over vanilla prefix-based source
   address validation.  While it is true that a large array of
   topologies and address allocation schemas will introduce complexities
   with automation of port-MAC-IP binding specifications, application of
   source address validation for static and common dynamic addressed
   allocation environments (e.g., DHCP) would significantly raise the
   bar for effectively launching spoof-based attacks.

8.  Deployment Considerations

   From a global Internet perspective, deployment of anti- spoofing
   techniques tends to suffer from a "tragedy of the commons" situation.
   That is, there is a general consensus that everyone should implement
   anti-spoofing measures, yet individual organizations don't want to
   bear the cost of deployment themselves, often because demonstrating
   direct tangible return on investment is not possible.  Upon analysis,
   it often seems apparent that local implementation of anti-spoofing
   measures is of more benefit to the "greater Internet" than the local
   network domain itself.  A similar situation occurs with de-
   aggregation of Internet routing information for multi-homing and
   traffic engineering purposes, as well as the lack of explicit inter-
   domain routing prefix filters on the Internet.

   Until network operators begin to accept that their local design
   choices have global implications, and act upon this responsibility,
   the problem is not going to go away.

   Ideally, with additional work in the areas of SAVI to ease deployment
   and management burdens, the deployment cost to operators will
   decrease and more wide-scale deployment will continue.  Furthermore,
   application of SAVI-like techniques provides more obvious benefits to
   network administrators that are concerned with MITM and similar

9.  Security Considerations

   This document provides limited discussion of some security threats
   source address validation improvements will help to mitigate.  It is
   not meant to be all-inclusive, either from a threat analysis
   perspective, or from the source address verification application

McPherson, Baker                                   Section 9.  [Page 20]

INTERNET-DRAFT           Expires: September 2008              March 2008

   It is seductive to think of SAVI solutions as providing the ability
   to use this technology to trace a datagram to the person, or at least
   end system, that originated it.  For several reasons, the technology
   can be used to derive circumstantial evidence, but does not actually
   solve that problem.

   In the Internet Layer, the source address of a datagram should be the
   address of the system that originated it and to which any reply is
   expected to come.  But systems fall into several broad categories.
   Many are single user systems, such as laptops and PDAs.  Multi-user
   systems are commonly used in industry, and a wide variety of
   middleware systems and application servers have no user at all, but
   by design relay messages or perform services on behalf of users of
   other systems (e.g., SMTP and peer-to-peer file sharing).

   Until every Internet-connected network implements source address
   validation at the ultimate network ingress, and assurances exist that
   intermediate devices are to never modify datagram source addresses,
   source addresses must not be used as an authentication mechanism.
   The only technique to unquestionably verify source addresses of a
   received datagram are cryptographic authentication mechanisms such as

10.  IANA Considerations

   This document introduces no IANA considerations.

McPherson, Baker                                  Section 10.  [Page 21]

INTERNET-DRAFT           Expires: September 2008              March 2008

11.  Acknowledgments

   Your name could be here....

   A portion of the primer text in this document came directly from
   [savi-operational], authored by Fred Back and Ralph Droms.

McPherson, Baker                                  Section 11.  [Page 22]

INTERNET-DRAFT           Expires: September 2008              March 2008

12.  References

12.1.  Normative References

   [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3",
   BCP 9, RFC 2026, October 1996.

   [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997

12.2.  Informative References

     "Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07,

     "Source address validation in the local environment", Fred Baker,

     "IPv4/IPv6 Source Address Verification", Fred Baker, Ralph Droms,

     "Multiprefix IPv6 Routing for Ingress Filters", Fred Baker,

              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X, September 2004.

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC826]  Plummer, D., "Ethernet Address Resolution Protocol: Or

McPherson, Baker                                Section 12.2.  [Page 23]

INTERNET-DRAFT           Expires: September 2008              March 2008

              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
              Internet Service Provider Environments", RFC 4778,
              January 2007.

13.  Authors' Addresses

McPherson, Baker                                  Section 13.  [Page 24]

INTERNET-DRAFT           Expires: September 2008              March 2008

   Danny McPherson
   Arbor Networks, Inc.
   Email:  danny@arbor.net

   Fred Baker
   Cisco Systems
   Email: fred@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

McPherson, Baker                                  Section 13.  [Page 25]

INTERNET-DRAFT           Expires: September 2008              March 2008



   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

McPherson, Baker                                  Section 13.  [Page 26]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/