diff options
Diffstat (limited to 'doc/rfc/rfc6959.txt')
| -rw-r--r-- | doc/rfc/rfc6959.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc6959.txt b/doc/rfc/rfc6959.txt new file mode 100644 index 0000000..ca7699d --- /dev/null +++ b/doc/rfc/rfc6959.txt @@ -0,0 +1,1403 @@ + + + + + + +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] + |