GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6959

Internet Engineering Task Force (IETF) D. McPherson Request for Comments: 6959 VeriSign, Inc. Category: Informational F. Baker ISSN: 2070-1721 Cisco Systems

                                                            J. Halpern
                                                              Ericsson
                                                              May 2013
     Source Address Validation Improvement (SAVI) Threat Scope

Abstract

 The Source Address Validation Improvement (SAVI) effort aims to
 complement ingress filtering with finer-grained, standardized IP
 source address validation.  This document describes threats enabled
 by IP source address spoofing both in the global and finer-grained
 context, describes currently available solutions and challenges, and
 provides a starting point analysis for finer-grained (host
 granularity) anti-spoofing work.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6959.

McPherson, et al. Informational [Page 1] RFC 6959 SAVI Threat Scope May 2013

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Overview ........................................................3
 2. Glossary of Terms ...............................................5
 3. Spoof-Based Attack Vectors ......................................6
    3.1. Blind Attacks ..............................................6
         3.1.1. Single-Packet Attacks ...............................6
         3.1.2. Flood-Based DoS .....................................7
         3.1.3. Poisoning Attacks ...................................8
         3.1.4. Spoof-Based Worm/Malware Propagation ................8
         3.1.5. Reflective Attacks ..................................8
         3.1.6. Accounting Subversion ...............................9
         3.1.7. Other Blind Spoofing Attacks ........................9
    3.2. Non-blind Attacks ..........................................9
         3.2.1. Man in the Middle (MITM) ............................9
         3.2.2. Third-Party Recon ..................................10
         3.2.3. Other Non-blind Spoofing Attacks ...................10
 4. Current Anti-spoofing Solutions ................................11
    4.1. Topological Locations for Enforcement .....................13
         4.1.1. Host to Link-Layer Neighbor via Switch .............13
         4.1.2. Upstream Switches ..................................13
         4.1.3. Upstream Routers ...................................14
         4.1.4. ISP Edge PE Router .................................14
         4.1.5. ISP NNI Router to ISP NNI Router ...................15
         4.1.6. Cable Modem Subscriber Access ......................15
         4.1.7. DSL Subscriber Access ..............................15
    4.2. Currently Available Tools .................................16
         4.2.1. BCP 38 .............................................16
         4.2.2. Unicast RPF ........................................16
         4.2.3. Port-Based Address Binding .........................16
         4.2.4. Cryptographic Techniques ...........................17
         4.2.5. Residual Attacks ...................................18

McPherson, et al. Informational [Page 2] RFC 6959 SAVI Threat Scope May 2013

 5. Topological Challenges Facing SAVI .............................18
    5.1. Address Provisioning Mechanisms ...........................18
    5.2. LAN Devices with Multiple Addresses .......................18
         5.2.1. Routers ............................................18
         5.2.2. NATs ...............................................19
         5.2.3. Multi-instance Hosts ...............................19
         5.2.4. Multi-LAN Hosts ....................................20
         5.2.5. Firewalls ..........................................20
         5.2.6. Mobile IP ..........................................20
         5.2.7. Other Topologies ...................................21
    5.3. IPv6 Considerations .......................................21
 6. Analysis of Host Granularity Anti-spoofing .....................21
 7. Security Considerations ........................................22
    7.1. Privacy Considerations ....................................23
 8. Acknowledgments ................................................24
 9. References .....................................................24
    9.1. Normative References ......................................24
    9.2. Informative References ....................................24

1. Overview

 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
 [RFC2460], employs 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.  In particular, the network does not track any state
 about the hosts using the network.  This is normally a benefit.
 However, as a consequence of this, hosts generating packets for
 transmission have the opportunity to spoof (forge) the source address
 of packets that they transmit, as the network does not have any way
 to tell that some of the information is false.
 Source address validation is necessary in order to detect and reject
 spoofed IP packets in the network, and contributes to the overall
 security of IP networks.  This document deals with the subset of such
 validation done by the network based on observed traffic and policy.
 Such source address validation techniques enable detection and
 rejection of many 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 packet.

McPherson, et al. Informational [Page 3] RFC 6959 SAVI Threat Scope May 2013

 Solutions such as those described in BCP 38 [RFC2827] provide
 guidelines for one such technique for network ingress filtering.
 However, if these techniques are not implemented at the ingress point
 of the IP network, then the validity of the source address cannot be
 positively ascertained.  Furthermore, BCP 38 only implies source
 address validation at the Internet layer and is most often
 implemented on IP subnetwork address boundaries.  One of the
 difficulties in encouraging the deployment of BCP 38 is that there is
 relatively little benefit until it is very widely deployed, which is
 not yet the case.
 Hence, in order to try to get better behavior, it is helpful to look
 for an application like that described in BCP 38, but one that can be
 applied locally and give locally beneficial results.  The local
 benefit would provide a reason for the site to deploy, while moving
 the Internet as a whole towards an environment where BCP 38 is widely
 effected.  SAVI is aimed at providing more specific protection
 locally, with the benefit of better local behavior and, in
 conjunction with appropriate logging, better local traceability,
 while also providing better compliance with the cases dealt with by
 BCP 38.
 It should be noted that while BCP 38 directs providers to provide
 protection from spoofed prefixes, it is clearly desirable for
 enterprise operators to provide that protection more locally, and
 with better traceability.  This allows the enterprise to be a better
 Internet participant and to quickly detect and remedy problems when
 they occur.  For example, when an enterprise receives a report of an
 attack originating within that enterprise, the operational staff
 desires to be able to track from the IP address sourcing the attack
 to the particular machine within the enterprise that is the source.
 This is typically simpler and more reliable than other techniques,
 such as trying to find the attack in ongoing outbound traffic.  To do
 this, the enterprise needs usable address assignment and usage
 information (appropriate logging), as well as accurate information
 (SAVI), to determine that no other machine could have been using that
 address.
 Also, there is a possibility that in a LAN environment where multiple
 hosts share a single LAN or IP port on a switch or router, one of
 those hosts may 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 exist with source address spoofing.
 This document provides additional details regarding spoof-based
 threat vectors and discusses implications of various network
 topologies.

McPherson, et al. Informational [Page 4] RFC 6959 SAVI Threat Scope May 2013

2. Glossary of Terms

 The following acronyms and terms are used throughout this memo.
 Binding Anchor:  The relationship used by a device performing source
    address enforcement to perform the validation and enforcement.
    Examples in different situations include Layer 2 addresses or
    physical ports.
 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 Edge, 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 or comparable IEEE 802 series
    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 Edge router.  This router faces a customer of an
    ISP.
 Spoofing:  The act of sending a datagram header whose contents at the
    link layer or network layer do not match the network policies and
    activities on address assignment or claiming.  Generally, this
    corresponds to sending messages with source network or link-layer
    information that is assigned to or currently properly claimed by
    some other devices in the network.
 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
    dropped.

McPherson, et al. Informational [Page 5] RFC 6959 SAVI Threat Scope May 2013

3. Spoof-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 spoof-based attack
 vectors exist: blind attacks and non-blind attacks.  The following
 sections provide some information on blind and non-blind attacks;
 these sections also include information on attacks where the spoofing
 is primarily intended to interfere with tracing the attacks, as well
 as attacks where spoofing the source address is a necessary component
 to the damage or interference.

3.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 data path between the attack source(s) and the target
 systems.  In this situation, the attacker has no access to the source
 and target systems.

3.1.1. Single-Packet Attacks

 One type of blind attacks, which we'll refer to here as "single-
 packet DoS (Denial of Service) attacks", involves an attacking system
 injecting spoofed information into the network, which either results
 in a complete crash of the target system, or in some manner poisons
 some network configuration or other information on a target system so
 as to impact network or other services.
 An example of an attack that can cause a receiving system to crash is
 what is called a LAND (Local Area Network Denial) attack.  A LAND
 attack would consist of an attacking system sending a packet (e.g.,
 TCP SYN) to a target system that contains both a source and
 destination address of that target system.  The packet would also
 contain a single value for the port number, used as both the source
 and destination port number.  Certain target systems will then "lock
 up" when creating connection state associated with the packet or
 would get stuck in a state where a target system continuously replies
 to itself.  As this is an attack that relies on bugs in the target,
 it is possible, but by no means certain, that this threat is no
 longer viable.
 Another form of blind attack is a RST (reset) probe ([RFC4953],
 Section 2.3).  The attacker sends a series of packets to a
 destination that is engaged in a long-lived TCP session.  The packets
 are RST packets, and the attacker uses the known source and
 destination addresses and port numbers, along with guesses at the
 sequence number.  If he can send a packet close enough to the right

McPherson, et al. Informational [Page 6] RFC 6959 SAVI Threat Scope May 2013

 value, in theory he can terminate the TCP connection.  While there
 are various steps that have been developed to ameliorate this attack,
 preventing the spoofing of source addresses completely prevents the
 attack from occurring.

3.1.2. Flood-Based DoS

 Flood-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 trace back.  In particular, there may be one or
 more attacking sources beyond a network's border, and the attacking
 sources may or may not be legitimate sources; it's difficult to
 determine if the sources are not directly connected to the local
 routing system.  These attacks might be seen as primarily needing to
 be addressed by BCP 38 deployment, which is not in scope for this
 document.  However, as noted earlier, deployment of SAVI can help
 remediate lack of BCP 38 deployment, and even when BCP 38 is
 deployed, SAVI can help provide useful information for responding to
 such attacks.
 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 address, 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.
 If an attacker can inject messages for a protocol that requires
 control-plane activity, it may be possible to deny network control
 services at a much lower attack level.  While there are various forms
 of protection deployed against this, they are by no means complete.
 Attacks that are harder to trace (such as with spoofed addresses) are
 of course of more concern.

McPherson, et al. Informational [Page 7] RFC 6959 SAVI Threat Scope May 2013

 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, in order to disrupt access to the target system by
 legitimate owner(s).

3.1.3. Poisoning Attacks

 While poisoning attacks can often be done with single packets, it is
 also true that a stream of packets can be used to find a window where
 the target will accept the incorrect information.  In general, this
 can be used to perform broadly the same kinds of poisonings as above,
 with more versatility.
 One important class of poisoning attacks are attacks aimed at
 poisoning network or DNS cache information, perhaps to simply break a
 given host's connection or to enable MITM (Man in the Middle) or
 other attacks.  Network-level attacks that could involve single-
 packet DoS include Address Resolution Protocol (ARP) cache poisoning
 and ICMP redirects.  The most obvious example, which depends upon
 falsifying an IP source address, is an on-link attacker poisoning a
 router's ARP or Neighbor Discovery (ND) cache.  The ability to forge
 a source address can also be helpful in causing a DNS cache to accept
 and use incorrect information.

3.1.4. Spoof-Based Worm/Malware Propagation

 Self-propagating malware has been observed that spoofs its source
 address when attempting to propagate to other systems.  Presumably,
 this was done to obfuscate the actual source address of the infected
 system.  This attack is important both in terms of an attack vector
 that SAVI may help prevent and as a problem that SAVI can help solve
 by tracing back to find infected systems.

3.1.5. Reflective Attacks

 Reflective amplification attacks -- wherein a sender sends a single
 packet to an intermediary, resulting in the intermediary sending a
 large number of packets, or much larger packets, to the target -- are
 a particularly potent DoS attack vector on the Internet today.  Many
 of these attacks rely on using a false source address, so that the
 amplifier attacks the target by responding to the messages.
 DNS is one of the common targets of such attacks.  The amplification
 factor observed for attacks targeting DNS root and other top-level
 domain name infrastructures in early 2006 was on the order of 72:1
 [VRSN-REPORT].  The result was that just 27 attacking sources with
 512 kbps of upstream attack bandwidth could generate 1 Gbps of
 response attack traffic towards a target system.

McPherson, et al. Informational [Page 8] RFC 6959 SAVI Threat Scope May 2013

 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 a (spoofed) ICMP echo request from an
 attacker and generating a large amount of ICMP echo response traffic
 directed towards a target system.  These attacks have been
 particularly effective in large campus LAN environments where 50K or
 more hosts might reside on a single subnet.

3.1.6. Accounting Subversion

 If an attacker wishes to distribute content or other material in a
 manner that employs protocols that require only unidirectional
 flooding and generate no end-to-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.
 While this particular attack has not been observed, it is included
 here to reflect the range of power that spoofed addresses may have,
 even without the ability to receive responses.

3.1.7. 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
 network.  It may also be possible in some environments to use
 spoofing techniques to perform blind or non-blind attacks on the
 routers in a site or in the Internet.  There are many techniques to
 mitigate these attacks, but it is well known that there are
 vulnerabilities in this area.

3.2. Non-blind Attacks

 Non-blind attacks often involve mechanisms such as eavesdropping on
 connections, resetting state so that new connections may be hijacked,
 and an array of other attack vectors.  Perhaps the most common of
 these attack vectors are known as man-in-the-middle attacks.  In this
 case, we are concerned not with an attacker who can modify a stream,
 but rather with one who has access to information from the stream and
 uses that information to launch his own attacks.

3.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 oftentimes 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 wish to insert themselves in the forwarding path.

McPherson, et al. Informational [Page 9] RFC 6959 SAVI Threat Scope May 2013

 For example, an attacker with access to a host on a 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 in
 IPv4, the attacker might transmit gratuitous ARP [RFC0826] 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 maps to its own Layer 2 address.  The source IP address
 in this case is spoofed.  Similar vulnerabilities exist in the IPv6
 ND protocol [RFC4861], although the multicast requirements of the
 IPv6 ND protocol make this harder to perform with the same
 generality.

3.2.2. Third-Party Recon

 Another example of a non-blind attack is third-party reconnaissance.
 The use of spoofed addresses, while not necessary for this, can often
 provide additional information and helps mask the traceability of the
 activity.  The attack involves sending 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 middlebox, they would be able to identify what
 IP-layer filtering policies may be in place to protect that system.

3.2.3. Other Non-blind Spoofing Attacks

 There are presumably many other attacks that can be performed based
 on the ability to spoof source addresses while seeing the target.
 Among other attacks, if there are multiple routers on-link with
 hosts, a host may be able to cause problems for the routing system by
 replaying modified or unmodified routing packets as if they came from
 another router.

McPherson, et al. Informational [Page 10] RFC 6959 SAVI Threat Scope May 2013

4. Current Anti-spoofing Solutions

 The goal of this work is to reduce datagrams with spoofed IP
 addresses from the Internet.  This can be aided by identifying and
 dropping datagrams whose source address binding is incompatible with
 the Internet topology and learned information.  This can be done at
 sites where the relationship between the source address and topology
 and binding information can be checked.  For example, with these
 bindings, in many networks 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 explicitly identified as appropriate for
    the physical topology; for example, the source address is
    appropriate for the Layer 2 switch port through which the datagram
    was received.
 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).
 In general, this involves two kinds of inspection.  The primary
 action is checking the source IP address in the IP header of IP
 packets.  In order to support such checking, the claimed or assigned
 IP addresses in messages concerned with such claims or assignments
 (IP ARP Requests and Responses, DHCP Replies, IPv6 ND Duplicate
 Address Detection (DAD) messages, etc.)  must also be examined and,
 where appropriate, verified.  SAVI is not concerned with verifying IP
 addresses in the contents of arbitrary higher-level protocol
 messages.
 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
 dropping traffic that is clearly inappropriate and in maintaining
 knowledge of the level of trust one can place in an address.

McPherson, et al. Informational [Page 11] RFC 6959 SAVI Threat Scope May 2013

           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 related paths where a source address can be
 validated:
 o  Host to switch, including host to host via the switch
 o  Host to enterprise CPE router
 o  Enterprise CPE router to ISP edge PE router, and the reverse
 o  ISP NNI router to ISP NNI router
 In general, datagrams with spoofed IP 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
 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, as well as the prefix aggregation in place
 between the spoofing detection and the source of the datagram.

McPherson, et al. Informational [Page 12] RFC 6959 SAVI Threat Scope May 2013

4.1. Topological Locations for Enforcement

 There are a number of kinds of places, which one might call
 topological locations, where solutions may or should be deployed.  As
 can be seen in the details below, as the point of enforcement moves
 away from a single cable attached directly to the host being
 validated, additional complications arise.  It is likely that fully
 addressing many of these cases may require additional coordination
 mechanisms across the device that covers the disparate paths.

4.1.1. Host to Link-Layer Neighbor via 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 validated against each
 other, and potentially against the physical port being used.  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 a
 first-hop router, or switch on the link.  The first-hop switch has
 the most precise information for this.
 On a truly shared medium link, such as classic Ethernet, the best
 that can be done is to validate 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 Layer 2 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.
 Other kinds of links may fall at different places in this spectrum,
 with some wireless links having easier ways of identifying individual
 devices than others, for example.

4.1.2. Upstream Switches

 In many topologies, there can be additional switches between the
 host-attached switch and the first router in the network.  In these
 cases, additional issues can arise that affect SAVI operations.  If
 the bridging topologies that connect the switches change, or if the
 Link Aggregation Control Protocol (LACP) [IEEE802.1AX], the Virtual
 Router Redundancy Protocol (VRRP), or link management operations
 change the links that are used to deliver traffic, the switch may
 need to move the SAVI state to a different port, or the state may
 need to be moved or reestablished on a different switch.

McPherson, et al. Informational [Page 13] RFC 6959 SAVI Threat Scope May 2013

4.1.3. 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 a downstream
 router from which the datagram was received.
 Options include the use of simple access lists or the use of Unicast
 Reverse Path Forwarding (uRPF).  Access lists are generally
 appropriate only for the simplest cases, as management can be
 difficult.  Strict uRPF accepts the source address on a datagram if
 and only if it comes from a direction that would be 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].
 In many cases, this router has access to information about what IP
 prefixes are to be used on a given subnet.  This might be because it
 delegated that prefix through DHCP or monitored such a delegation.
 It may have advertised that prefix in IPv6 Neighbor Discovery Router
 Advertisement messages, or monitored such an advertisement.  These
 can be seen as generalizations of the access lists above.  When the
 topology permits, the router can enforce that these prefixes are used
 by the hosts.

4.1.4. 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
 validate this.
 Conversely, if the provider has assigned a single IP address to the
 customer (for example, with IPv4 NAT in the CPE), PE enforcement of
 BCP 38 can be on the full address, simplifying many issues.

McPherson, et al. Informational [Page 14] RFC 6959 SAVI Threat Scope May 2013

4.1.5. 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 that network ingress
 filtering policy be implemented on all customer 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 [RFC4271] and use that to
 advertise the level of trust to its BGP peers.
 In this case, uRPF is less effective as a validation tool, due to
 asymmetric routing.  However, when it can be shown that spoofed
 addresses are present, the procedure can be applied.
 Part of the complication here is that in the abstract, it is very
 difficult to know what addresses should appear in packets sent from
 one ISP to another.  Hence, packet-level filtering and enforcement
 are very difficult at this point in the network.  Whether one views
 this as specific to the NNI, or a general property of the Internet,
 it is still a major factor that needs to be taken into account.

4.1.6. Cable Modem Subscriber Access

 Cable Modem Termination Systems (CMTS) employ Data Over Cable Service
 Interface Specification (DOCSIS) Media Access Control (MAC) domains.
 These share some properties with general switched networks, as
 described above in Section 4.1.1, and some properties with DSL access
 networks, as described below in Section 4.1.7.  They also often have
 their own provisioning and monitoring tools that may address some of
 the issues described here.

4.1.7. DSL Subscriber Access

 While DSL subscriber access can be bridged or routed, as seen by the
 service provider's device, it is generally the case that the
 protocols carry enough information to validate which subscriber is
 sending packets.  Thus, for ensuring that one DSL subscriber does not
 spoof another, enforcement can generally be done at the aggregation
 router.  This is true even when there is a bridged infrastructure
 among the subscribers, as DSL access generally requires all
 subscriber traffic to go through the access aggregation router.

McPherson, et al. Informational [Page 15] RFC 6959 SAVI Threat Scope May 2013

 If it is desirable to provide spoofing protection among the devices
 within a residence, that would need to be provided by the CPE device,
 as the ISP's router does not have enough visibility to do that.  It
 is not clear at this time that this problem is seen as a relevant
 threat.

4.2. Currently Available Tools

 There are a number of tools that have been developed, and have seen
 some deployment, for addressing these attacks.

4.2.1. BCP 38

 If BCP 38 [RFC2827] 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.

4.2.2. Unicast RPF

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

4.2.3. Port-Based Address Binding

 Much of the work of SAVI is initially targeted at minimizing source
 address spoofing in the LAN.  In particular, if mechanisms can be
 defined to accommodate configuration of port binding information for
 IP, either to a port, to an unchangeable or authenticated MAC
 address, or to other credentials in the packet such that an impostor
 cannot create the needed values, a large portion of the spoofing
 threat space in the LAN can be marginalized.
 However, establishing this binding is not trivial and varies across
 both topology types and address allocation mechanisms.

4.2.3.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 areas involve
 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 via a single physical port.  Furthermore, if one

McPherson, et al. Informational [Page 16] RFC 6959 SAVI Threat Scope May 2013

 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 reclaimed.

4.2.3.2. Automated Binding

 For IPv4, the primary and very widely used automated address
 assignment technique is DHCP-based address assignment.  This can be
 coupled with filtering policies that control which hosts can
 originate DHCP replies.  Under such circumstances, SAVI switches can
 treat DHCP replies as authoritative sources of IP address binding
 information.  By eavesdropping on the DHCP exchanges, the SAVI switch
 can create the bindings needed for address usage enforcement.
 For IPv6, there are two common automated address assignment
 techniques.  While there are many variations and details, for
 purposes of understanding the threats and basic responses, these are
 Stateless Address Autoconfiguration (SLAAC) and DHCP-based IPv6
 address assignment.  For DHCP-based IPv6 address assignment, the
 techniques above are applicable and suitable.
 When SLAAC is used for IPv6 address assignment, the switches can
 observe the duplicate address detection messages and use those to
 create the enforcement bindings.  This enables the switches to ensure
 that only properly claimed IP addresses are used for data traffic.
 It does not enforce that these addresses are assigned to the hosts,
 since SLAAC does not have a notion of address assignment.

4.2.3.3. IEEE 802.1x

 IEEE 802.1x is an authentication protocol that permits a network to
 determine the identity of a user seeking to join it and apply
 authorization rules to permit or deny the action.  In and of
 themselves, such tools confirm only that the user is authorized to
 use the network, but they do not enforce what IP address the user is
 allowed to use.  It is worth noting that elements of 802.1x may well
 be useful as binding anchors for SAVI solutions.

4.2.4. Cryptographic Techniques

 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 for IPv4 does not use such protection.  While Secure Neighbor
 Discovery (SEND) provides such protection for the IPv6 ND protocol,
 SEND is not widely used to date.  Usage of such techniques is outside
 the scope of this document.

McPherson, et al. Informational [Page 17] RFC 6959 SAVI Threat Scope May 2013

 While DNSSEC will significantly help protect DNS from the effects of
 spoof-based poisoning attacks, such protection does not help protect
 the rest of the network from spoofed attacks.

4.2.5. Residual Attacks

 It should be understood that not all combinations of network,
 service, and enforcement choices will result in a protectable
 network.  For example, if one uses conventional SLAAC in a switched
 network, but tries to only provide address enforcement on the routers
 on the network, then the ability to provide protection is severely
 limited.

5. Topological Challenges Facing SAVI

 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
 address.

5.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, DHCPv6 for address allocation, and
 IPv6 Stateless Address Autoconfiguration.

5.2. LAN Devices with Multiple Addresses

 From the perspective of network topology, consider hosts connected to
 switch ports that may have one or more IP addresses, and devices that
 forward packets from other network segments.  It is much harder to
 enforce port-MAC-IP bindings on traffic from such hosts and devices
 than for traffic from more simply connected devices.

5.2.1. Routers

 Routers are the most obvious examples of devices for which it is
 problematic to implement port-MAC-IP bindings.  Routers not only
 originate packets themselves and often have multiple interfaces, but
 also forward packets from other network segments.  As a result, it's

McPherson, et al. Informational [Page 18] RFC 6959 SAVI Threat Scope May 2013

 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.

5.2.2. NATs

 Validating traffic from prefix-based and multi-address NATs is also
 problematic, for the same reasons as for routers.  Because they may
 forward traffic from an array of addresses, validation requires
 advance knowledge of the IPs that should be associated with a given
 port-MAC pair.

5.2.3. Multi-instance Hosts

 Another example that introduces complexities is that of multi-
 instance hosts attached to a switch port.  These are single physical
 devices that internally run multiple physical or logical hosts.  When
 the device is a blade server, e.g., with internal blades each hosting
 a physical machine, there is essentially a physical switch inside the
 blade server.  While feasible, this creates some complexity for
 determining where enforcement logic can or should live.
 Logically distinct hosts, such as are provided by many varieties of
 virtualization logic, result in a single physical host and connect to
 a single port on the Ethernet switch in the topology, actually having
 multiple internal virtual machines.  Each virtual machine may have
 its own IP and MAC addresses.  These are connected by what is
 essentially (or sometimes literally) an internal LAN switch.  While
 this internal switch may be a SAVI enforcement point to help control
 threats among the virtual hosts, or between virtual hosts and other
 parts of the network, such enforcement cannot be counted on in all
 implementations.  If the virtual machines are interconnected by the
 internal switch, then that logical device is the first switch for the
 purposes of this analysis.
 A further complication with multi-instance hosts is that in many
 environments, these hosts may move while retaining their IP
 addresses.  This can be an actual relocation of the running software,
 or a backup instance taking over the functions of the software.  In
 both cases, the IP address will appear at a new topological location.
 Depending upon the protocols used, it may have the same MAC address
 or a different one, and the system may or may not issue a gratuitous
 ARP request after relocation.  When such a move is done without
 changing the MAC address, the SAVI switches will need to update their
 state.  While ARP may be helpful, traffic detection, switch-based
 neighbor solicitation, interaction with an orchestration system, or
 other means may be used.

McPherson, et al. Informational [Page 19] RFC 6959 SAVI Threat Scope May 2013

5.2.4. Multi-LAN Hosts

 Multi-interface hosts, in particular those that are multihomed 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 a third interface is used as the source address of a
 packet forwarded through an 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 priori knowledge of address assignment and topology
 is required.
 While it is rare to use loopback addressing or to send packets out of
 one interface with the source address of another, these rarities do
 legitimately occur.  Some servers, particularly ones that have
 underlying virtualization, use loopback techniques for management.

5.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.

5.2.6. Mobile IP

 Mobile IP hosts in both IPv4 and IPv6 are proper members of the site
 where they are currently located.  Their care-of address is a
 properly assigned address that is on the link they are using, and
 their packets are sent and received using that address.  Thus, they
 do not introduce any additional complications.  (There was at one
 time consideration of allowing mobile hosts to use their home address
 when away from home.  This was not done, precisely to ensure that
 mobile hosts comply with source address validity requirements.)
 Mobile hosts with multiple physical interfaces fall into the cases
 above.
 Mobile IP Home Agents (HAs) are somewhat more interesting.  Although
 they are (typically) fixed devices, they are required to send and
 receive packets addressed from or to any currently properly
 registered mobile node.  From an analysis point of view, even though
 the packets that an HA handles are actually addressed to or from the
 link the HA is on, it is probably best to think of them as routers,
 with a virtual interface to the actual hosts they are serving.  Thus,
 if the Mobile IP HA is trusted, it can itself perform IP source
 address checking on the packets it forwards on behalf of mobile
 nodes.  This would utilize bindings established by the Mobile IP
 registration mechanisms.

McPherson, et al. Informational [Page 20] RFC 6959 SAVI Threat Scope May 2013

5.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 a packet that it originated may be problematic.
 Additionally, address allocation schemas introduce additional
 considerations when examining a given SAVI solutions space.

5.3. IPv6 Considerations

 IPv6 introduces additional capabilities that indirectly complicate
 the spoofing analysis.  IPv6 introduces and recommends the use of
 SLAAC [RFC4862].  This allows hosts to determine their IP prefix,
 select an Interface Identifier (IID), and then start communicating.
 While there are many advantages to this, the absence of control
 interactions complicates the process of behavioral enforcement.
 An additional complication is the very large IID space.  Again, this
 64-bit IID space provided by IPv6 has many advantages.  It provides
 the opportunity for many useful behaviors.  However, it also means
 that in the absence of controls, hosts can mint anonymous addresses
 as often as they like, modulo the idiosyncrasies of the duplicate
 address procedure.  Like many behaviors, this is a feature for some
 purposes and a problem for others.  For example, without claiming the
 entire IID space, an on-link attacker may be able to generate enough
 IP addresses to fill the Neighbor Discovery table space of the other
 Layer 3 (L3) devices on the link, including switches that are
 monitoring L3 behavior.  This could seriously interfere with the
 ability of other devices on the link to function.

6. Analysis of Host Granularity Anti-spoofing

 Applying anti-spoofing techniques at the host level enables a site to
 achieve several valuable objectives.  While it is likely the case
 that for many site topologies and policies full source spoofing
 protection is not possible, it is also true that for many sites there
 are steps that can be taken that provide benefit.
 One important class of benefit is masquerade prevention.  Security
 threats involving one machine masquerading as another, for example,
 in order to hijack an apparently secure session, can occur within a
 site with significant impact.  Having mechanisms such that host-
 facing devices prevent this is a significant intra-site security
 improvement.  Given that security experts report that most security
 breaches are internal, this can be valuable.  One example of this is
 that such techniques should mitigate internal attacks on the site
 routing system.

McPherson, et al. Informational [Page 21] RFC 6959 SAVI Threat Scope May 2013

 A second class of benefit is related to the traceability described
 above.  When a security incident is detected, either within a site or
 externally (and traced to the site), it can be critical to determine
 the actual source of the incident.  If address usage can be tied to
 the kinds of anchors described earlier, this can help in responding
 to security incidents.
 In addition to these local observable benefits, there can be more
 global benefits.  For example, if address usage is tied to anchors,
 it may be possible to prevent or control the use of large numbers of
 anonymous IPv6 addresses for attacks, or at least to trace even those
 attacks back to their source.
 As described below in the security considerations, these operational
 behaviors need to be evaluated in the context of the reduction in
 user privacy implied if one logs traffic bindings.  In particular, in
 addition to the architectural trade-offs, the network administrator
 must plan for the proper handling of this relevant privacy
 information about his users.

7. Security Considerations

 This document provides limited discussion of some security threats
 that 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 validation application side.
 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 users 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).
 Even if 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 cannot be used as an authentication mechanism.  The

McPherson, et al. Informational [Page 22] RFC 6959 SAVI Threat Scope May 2013

 only techniques for unquestionably validating source addresses of
 a received datagram are cryptographic authentication mechanisms
 such as IPsec.
 It must be presumed that there will be some failure modes in any SAVI
 deployment, given the history of technical security mechanisms.  A
 possible attack to be considered by network administrators is an
 inside attack probing the network for modes of spoofing that can be
 accomplished.  If the probes are conducted at a level below alarm
 thresholds, this might allow an internal attacker to safely determine
 what spoof modes he can use.  Thus, the use of these techniques must
 be managed in such a way as to avoid giving a false sense of security
 to the network administrator.

7.1. Privacy Considerations

 It should be understood that enforcing and recording IP address
 bindings have privacy implications.  In some circumstances, this
 binding data may be considered to be personally identifying
 information.  In general, collecting private information about users
 brings ethical and legal responsibilities to the network
 administrator.
 For this reason, collection and retention of logged binding
 information need to be considered carefully.  Prevention of spoofing
 does not in itself require such retention.  Analysis of immediate
 events may rely on having logs of current bindings.  Thus, privacy
 issues can be ameliorated by removing binding logs after the binding
 lifetimes expire.  Logs of apparent spoof attempts are a separate
 matter and may require longer retention to detect patterns of
 deliberate or accidental abuse.
 With operations of the type described here, the network administrator
 is collecting information about where on his network the user is
 active.  In addition, the recorded bindings supplement address usage
 information about users that is available from DHCP logs.  For
 example, if IPv6 SLAAC is being used, and IP to Layer 2 address
 bindings are being logged, the administrator will have access to
 information associating users with their IP addresses even if IPv6
 privacy addresses are used.
 In addition to this, care must be taken in attributing actions to
 users on the basis of this sort of information.  Whatever the
 theoretical strength of the tools, administrators should always allow
 for such information being wrong and should be careful about any
 actions taken on the basis of apparent attribution.  These techniques
 do nothing about address spoofing from other sites, so any evaluation
 of attribution also needs to allow for such cases.

McPherson, et al. Informational [Page 23] RFC 6959 SAVI Threat Scope May 2013

8. Acknowledgments

 A portion of the primer text in this document came directly from
 [SAVA], authored by Fred Baker and Ralph Droms.  Many thanks to
 Christian Vogt, Suresh Bhogavilli, and Pekka Savola for contributing
 text and a careful review of this document.

9. References

9.1. Normative References

 [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
            September 1981.
 [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.

9.2. Informative References

 [IEEE802.1AX]
            IEEE, "IEEE Standard for Local and metropolitan area
            networks - Link Aggregation", IEEE 802.1AX, 2008.
 [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
            converting network protocol addresses to 48.bit Ethernet
            address for transmission on Ethernet hardware", STD 37,
            RFC 826, November 1982.
 [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.
 [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
            Networks", BCP 84, RFC 3704, March 2004.
 [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
            Protocol 4 (BGP-4)", RFC 4271, January 2006.
 [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
            "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
            September 2007.
 [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            Address Autoconfiguration", RFC 4862, September 2007.
 [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",
            RFC 4953, July 2007.

McPherson, et al. Informational [Page 24] RFC 6959 SAVI Threat Scope May 2013

 [SAVA]     Baker, F. and R. Droms, "IPv4/IPv6 Source Address
            Verification", Work in Progress, June 2007.
 [VRSN-REPORT]
            Silva, K., Scalzo, F., and P. Barber, "Anatomy of Recent
            DNS Reflector Attacks from the Victim and Reflector Point
            of View", VeriSign White Paper, April 2006.

Authors' Addresses

 Danny McPherson
 VeriSign, Inc.
 EMail: dmcpherson@verisign.com
 Fred Baker
 Cisco Systems
 EMail: fred@cisco.com
 Joel M. Halpern
 Ericsson
 EMail: joel.halpern@ericsson.com

McPherson, et al. Informational [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6959.txt · Last modified: 2013/05/29 16:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki