RFC 6959
Source Address Validation Improvement (SAVI) Threat Scope
Source Address Validation Improvement (SAVI) Threat Scope 🎀
📮 RFC 6959 · Informational · May 2013 · ISSN 2070-1721
Authors: D. McPherson (VeriSign, Inc.), F. Baker (Cisco Systems), and J. Halpern (Ericsson). This one is Informational, not Standards Track, so it's a helpful analysis rather than a spec. It doesn't obsolete or update any other RFCs. 💅
Abstract 🌸
The Source Address Validation Improvement (SAVI) effort is all about adding finer-grained, standardized IP source address validation on top of ingress filtering 🦋. This document covers the threats that come from IP source address spoofing, both globally and at a more granular level. It also looks at the solutions that exist today and where they struggle, then gives 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's published for informational purposes. 📚
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, has received public review, and has been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for more on that. 🫶
Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6959. 🌈
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) as in effect on the date of publication. Please read these carefully, because 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 they 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
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 ....................................241. Overview 🦋
Okay so the Internet Protocol, meaning IPv4 [RFC0791] and IPv6 [RFC2460], runs on a connectionless, hop-by-hop packet forwarding model 📦. When a host on an IP network wants to talk to another host, it builds an IP packet that carries source and destination addressing information, along with some other options. 💌
At the Internet layer, there's typically no required transactional state when hosts talk to each other on the network. The network doesn't keep track of any state about the hosts using it. Honestly that's usually a good thing ✨. The catch is that hosts sending packets get to spoof (forge) the source address of what they send, because the network has no way to tell that some of that information is false. 🙈
Source address validation is necessary to detect and reject spoofed IP packets on the network, and it helps keep IP networks secure overall 🔐. This document only deals with the part of that validation the network does based on observed traffic and policy. These techniques can catch and reject lots of spoofed packets, and they also implicitly give some assurance that a packet's source address really belongs to the system that sent it. 💖
BCP 38 [RFC2827] gives guidelines for one such technique, network ingress filtering 🚧. But if these techniques aren't implemented at the ingress point of the IP network, the validity of the source address can't be positively confirmed. Also, BCP 38 only implies source address validation at the Internet layer, and it's most often implemented on IP subnetwork address boundaries. The tricky bit is that BCP 38 offers relatively little benefit until it's very widely deployed, and we're not there yet 😭.
So to get better behavior, it helps to look for something like BCP 38 that can be applied locally and gives local results. Local benefit is the reason a site would actually deploy it, and that moves the whole Internet toward a place where BCP 38 is widely put into effect 🌍. SAVI is aimed at that more specific, local protection. It brings better local behavior and, combined with appropriate logging, better local traceability 🔍. It also gives better compliance with the cases BCP 38 covers. Main character energy for local networks 👑.
BCP 38 tells providers to protect against spoofed prefixes, but it's clearly better for enterprise operators to do that protection more locally, with better traceability 🎀. That lets the enterprise be a better Internet participant and quickly detect and fix problems when they happen.
Here's a real example 🧐. Say an enterprise gets a report of an attack that's coming from inside the enterprise. The operations staff really wants to trace the IP address sending the attack to the exact machine inside the enterprise that's the source. That's usually simpler and more reliable than trying to catch the attack in ongoing outbound traffic 🫠. To pull this off, the enterprise needs usable address assignment and usage information (that's the appropriate logging) and accurate information (that's SAVI). With both, it can figure out that no other machine could have been using that address 🕵️♀️.
Also, on a LAN where multiple hosts share a single LAN or a single IP port on a switch or router, one of those hosts could spoof the source addresses of other hosts on the same local subnet 😬. Understanding these threats, and the topologies where they show up, is critical when you're assessing the threats that come with source address spoofing 🚨.
This document gives more details about spoof-based threat vectors and talks about what different network topologies mean for them 🦋💅.
2. Glossary of Terms ✨
okay bestie, here's the vocab list we need to know before anything else 📚 these acronyms and terms show up all over this memo, so keep them handy 🎀
- Binding Anchor: the relationship a device uses when it does source address enforcement. It's how the device validates and enforces. Depending on the situation, it could be a Layer 2 address or a physical port 🔗
- BGP: the Border Gateway Protocol, used to manage routing policy between big networks 🌐
- CPE Router: Customer Premises Equipment router. It's the router sitting on the customer's premises, whether the customer owns it or the provider does. It's also called the Customer Edge (or CE) router 🏠
- IP Address: an Internet Protocol address, IPv4 or IPv6 💅
- ISP: Internet Service Provider. Literally any person or company that delivers Internet service to someone else ☁️
- MAC Address: an Ethernet address or a comparable IEEE 802 series address 🧚
- NNI Router: Network-to-Network Interface router. This interface faces a similar system run by another ISP or some other big network 🤝
- PE Router: Provider Edge router. This one faces a customer of an ISP 🦋
- Spoofing: this one's giving sneaky energy 🙈 It's the act of sending a datagram header whose contents at the link layer or network layer don't match the network's policies and its activities around address assignment or claiming. Usually this means sending messages with source network or link-layer info that's assigned to, or already properly claimed by, some other device on the network 👀
- TCP: the Transmission Control Protocol, used on end systems to manage data exchange 💜
- uRPF: Unicast Reverse Path Forwarding. This is a procedure where the route table, which normally gets used to look up destination addresses and route toward them, gets used to look up the source address instead. The goal is to make sure you're routing away from it. When that test fails, the event may be logged, and the traffic is commonly dropped 🛑
3. Spoof-Based Attack Vectors 🕵️♀️
okay so spoofing happens all over the Internet, and most of the time it's kinda shady, like malicious or nefarious stuff 💀 Generally there are two classes of spoof-based attack vectors: blind attacks and non-blind attacks. The next sections give you the tea on both, plus attacks where spoofing is mainly there to mess with tracing, and attacks where spoofing the source address is a must-have piece of the damage or interference 🎀
3.1. Blind Attacks
Blind attacks usually happen when the attacker isn't on the same local area network as a source or a target, or when they have no access to the data path between the attack source(s) and the target systems. Basically the attacker has zero access to the source and target systems. Not ideal for them, but still dangerous 😬
3.1.1. Single-Packet Attacks
Here's one type of blind attack, which we'll call "single-packet DoS (Denial of Service) attacks" 💅 An attacking system injects spoofed info into the network. That either crashes the target system completely, or it poisons some network configuration or other info on the target so that network or other services get messed up 🫠
A classic example of an attack that can crash a receiving system is the LAND (Local Area Network Denial) attack. In a LAND attack, the attacker sends a packet (for example, a TCP SYN) to a target system. That packet has both the source and the destination address set to the target system's own address. It also has one single port number value, used as both the source and destination port number. Some target systems will "lock up" while they're creating connection state for that packet, or they'll get stuck in a state where they keep replying to themselves 🙀 Since this attack depends on bugs in the target, it's possible, but by no means certain, that this threat isn't viable anymore 🤞
Another blind attack is the RST (reset) probe ([RFC4953], Section 2.3). The attacker sends a bunch of packets to a destination that's in a long-lived TCP session. These packets are RST packets, and the attacker uses the known source and destination addresses and port numbers, plus guesses at the sequence number. If they can get close enough to the right sequence number value, in theory they can terminate the TCP connection 😭 There are various steps that have been developed to lessen this attack, but preventing the spoofing of source addresses completely stops the attack from happening at all 🛡️
3.1.2. Flood-Based DoS
Flood-based DoS attack vectors are super effective on the Internet today, no cap 🔥 They usually involve flooding a huge number of packets at a target system. The goal is to either exhaust connection state on the target, eat up all the packet-processing capacity of the target or the systems in between, or consume so much of the bandwidth available to the target that it's basically unreachable 🥀
These attacks don't need a reply from the target and don't need any legitimate transaction state, so attackers often try to hide who's generating the attack traffic by spoofing the source IP address of the flows. Ingress filtering isn't applied everywhere on the Internet yet, so spoof-based flooding attacks are typically really hard to trace back 🕵️♀️ There may be one or more attacking sources beyond a network's border, and those sources may or may not be legit. It's hard to figure out whether the sources are directly connected to the local routing system. These attacks are mostly something that BCP 38 deployment would address, but that's out of scope for this document. Still, as noted earlier, deploying SAVI can help make up for a lack of BCP 38 deployment, and even when BCP 38 is deployed, SAVI can still give you useful information for responding to these attacks 💖
Common flood-based DoS attacks today include SYN floods, ICMP floods, and IP fragmentation attacks 🌊 An attacker might use a single legit or spoofed fixed source address, but they often cycle through big chunks of address space instead. Because of that, trying to mitigate these attacks on the receiving end with source-based policies is extremely difficult 😩
If an attacker can inject messages for a protocol that needs control-plane activity, they might be able to shut down network control services at a much lower attack level. There are various protections deployed against this, but they're by no means complete 🚧 Attacks that are harder to trace (like the ones with spoofed addresses) are, of course, more concerning 👀
Also, the motivation behind spoof-based DoS attacks might actually be to get the target to filter explicitly on a given set of source addresses. The point is to disrupt access to the target for its legitimate owner(s) 😤
3.1.3. Poisoning Attacks
Poisoning attacks can often be done with single packets, but a stream of packets can also be used to find a window where the target will accept the incorrect information. In general, this can be used to do broadly the same kinds of poisoning as above, just with more versatility 🧪
One important class of poisoning attacks targets network or DNS cache information. The goal might be 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 on falsifying an IP source address, is an on-link attacker poisoning a router's ARP or Neighbor Discovery (ND) cache. Being able to forge a source address can also help cause a DNS cache to accept and use incorrect info 🫣
3.1.4. Spoof-Based Worm/Malware Propagation
Self-propagating malware has been observed spoofing its source address when it tries to spread to other systems. That was probably done to hide the actual source address of the infected system 🦠 This attack matters in two ways: it's an attack vector that SAVI may help prevent, and it's also a problem SAVI can help solve by tracing back to find infected systems 🔍
3.1.5. Reflective Attacks
Reflective amplification attacks (where a sender sends a single packet to an intermediary, and the intermediary sends a huge number of packets, or much larger packets, to the target) are a particularly potent DoS attack vector on the Internet today 📣 Lots of these attacks rely on a false source address, so the amplifier ends up attacking the target by responding to the messages 😈
DNS is one of the common targets of these attacks. The amplification factor observed for attacks aimed at DNS root and other top-level domain name infrastructures in early 2006 was on the order of 72:1 [VRSN-REPORT]. That means just 27 attacking sources with 512 kbps of upstream attack bandwidth could generate 1 Gbps of response attack traffic toward a target system 🤯
Smurf attacks use a similar reflective amplification attack vector. They exploit traditional default IP-subnet-directed broadcast address behaviors, which would make all the active hosts on a given subnet respond to a (spoofed) ICMP echo request from an attacker. That generates a large amount of ICMP echo response traffic aimed at a target system 🌪️ These attacks have been especially effective in big campus LAN environments, where 50K or more hosts might live on a single subnet 🏫
3.1.6. Accounting Subversion
If an attacker wants to distribute content or other material using protocols that only need unidirectional flooding and don't create any end-to-end transactional state, they might want to spoof the source IP address of that content. That helps them dodge detection or the accounting functions enabled at the IP layer 🎭 This particular attack hasn't been observed in the wild, but it's included here to show the range of power spoofed addresses can have, even without the ability to receive responses 🫥
3.1.7. Other Blind Spoofing Attacks
Other blind spoofing attacks might involve spoofing to exploit source routing or other policy-based routing implemented in a network 🗺️ In some environments, it may also be possible to use spoofing techniques to do 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's well known that there are vulnerabilities in this area 🥲
3.2. Non-blind Attacks
Non-blind attacks often involve things like eavesdropping on connections, resetting state so new connections can be hijacked, and a whole bunch of other attack vectors 🎣 The most common of these are probably man-in-the-middle attacks. In this case we're not worried about an attacker who can modify a stream. We're worried about one who can see info from the stream and uses that info to launch their own attacks 👀💅
3.2.1. Man in the Middle (MITM) 🕸️
okay so connection hijacking is kind of a classic MITM move 😭 To hijack a connection, an attacker usually has to be sitting in the forwarding path, and they often use TCP RST or other attacks to reset a transaction 💀 The attacker might have already compromised a system that's in the forwarding path, or they might want to wedge themselves into that path 🫣
Picture this: an attacker with access to a host on a LAN segment wants all the traffic on that segment headed for a default gateway address (or all addresses) to come to them instead 🙈 For IPv4, they could send gratuitous ARP [RFC0826] messages or ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff. That basically tells every host on the segment that the IP address(es) of the target(s) now map to the attacker's own Layer 2 address 📢 The source IP address in this case is spoofed. IPv6 ND [RFC4861] has similar vulnerabilities too, though its multicast requirements make it harder to pull off with the same generality 🦋
3.2.2. Third-Party Recon 🔍
Third-party reconnaissance is another non-blind attack, and it's giving sneaky 👀 Spoofed addresses aren't required for it, but they can give the attacker extra info and help hide where the activity is coming from 🥷 The attack works by sending packets at a target system and watching how the target or an intermediate system responds 💜 For example, if an attacker sends spoofed TCP SYN packets at a target from a big pile of source addresses and watches the replies from that target or some firewall or other middlebox in front of it, they can figure out which IP-layer filtering policies are protecting that system 🕵️♀️✨
3.2.3. Other Non-blind Spoofing Attacks 🌀
There are presumably tons of other attacks you can run if you can spoof source addresses and also see the target 😳 One example: if there are multiple routers on-link with hosts, a host could mess with the routing system by replaying modified or unmodified routing packets as if they came from another router 🙃 Chaotic, but iconic 💅
4. Current Anti-spoofing Solutions 🛡️✨
Okay bestie, the goal here is to cut down on datagrams with spoofed IP addresses on the Internet 🫶 One way to do that is to spot and drop datagrams whose source address binding doesn't fit the Internet topology or the info that's been learned 🧠 This can happen at sites where you can actually check the relationship between the source address, the topology, and the binding info. For example, with these bindings, in lots of networks, Internet devices can confirm that:
- The IP source address is appropriate for the lower-layer address (they both identify the same system).
- 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 the datagram came in through.
- The prefix that the IP source address belongs to is appropriate for the part of the network topology the IP datagram was received from. (You might not know the exact system, but it's reasonable to believe it's located in that part of the network 🗺️)
Generally, this involves two kinds of inspection 👀 The main one is checking the source IP address in the IP header of IP packets. To make that checking possible, the claimed or assigned IP addresses in messages about those claims or assignments (IP ARP Requests and Responses, DHCP Replies, IPv6 ND Duplicate Address Detection (DAD) messages, and so on) must also be examined and, where appropriate, verified 📋 SAVI isn't concerned with verifying IP addresses inside the contents of arbitrary higher-level protocol messages, though 🙅♀️
Filtering points farther from the source of the datagram can make less and less authoritative claims about whether the source address is valid 🫠 Even so, it's still worth dropping traffic that's clearly inappropriate, and keeping track of how much trust you can put in an address 💖
Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \\
( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | )
`. +----+ +------+ |Router| ,' \\ |Router| |Router| /
`---. Host-neighbor +------+' `.+------+ +--+---+,'
`----------------'' '--. |_.-'
`------------'|
|
Edge Network 2 ISP-ISP Ingress |
_.----------------. _.----------.|
,--'' `---. ,-'' |--.
,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\
`. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \\+------+ +------+ /
`----------------'' `. ,'
'--. ISP B _.-'
`----------''Figure 1: Points Where an Address Can Be Validated 🎀
Figure 1 shows five related paths where a source address can be validated 📍
- Host to switch, including host to host via the switch
- Host to enterprise CPE router
- Enterprise CPE router to ISP edge PE router, and the reverse
- ISP NNI router to ISP NNI router
Generally, datagrams with spoofed IP addresses can be detected and dropped by devices that have an authoritative mapping between IP addresses and the network topology 🧚 For example, a device with an authoritative table mapping link-layer addresses to IP addresses on a link can discard any datagram whose IP address isn't associated with the link-layer address in that datagram 🙌 How confident you can be in the source address depends on where the spoofing detection happens, plus the prefix aggregation between that point and the datagram's source 📊
4.1. Topological Locations for Enforcement 🗺️
There are a bunch of places, which you could call topological locations, where solutions may or should be deployed 💅 As you'll see below, the further the enforcement point moves away from a single cable plugged directly into the host being validated, the more complications pop up 😩 Fully handling a lot of these cases will probably need extra coordination mechanisms across the device covering the different paths 🫶
4.1.1. Host to Link-Layer Neighbor via Switch 🔌
The first place a datagram with a spoofed address can be caught is on the link the datagram's source is connected to ✨ There, the source link-layer and IP addresses are both available, so they can be checked against each other and maybe against the physical port being used 🙌 A datagram whose IP source address doesn't match the corresponding link-layer address can be dropped 🗑️ Of course, how much you trust the filtering depends on how much you trust the method used to develop the mappings 🤔 This can be applied by a first-hop router or a switch on the link, and the first-hop switch has the most precise info for it 💎
On a truly shared medium link, like classic Ethernet, the best you can do is validate the link-layer and IP addresses against the mappings 🫠 When the link isn't shared, like when hosts connect through a switch, the source host can be pinned down precisely based on the port the datagram came in on, or on the Layer 2 address if the switch knows it 🎯 Port identification stops malicious datagrams whose link-layer and IP addresses are both spoofed to imitate another host 🙅♀️
Other kinds of links can land at different spots on this spectrum. Some wireless links, for example, have easier ways of identifying individual devices than others 📡
4.1.2. Upstream Switches 🔁
In lots of topologies, there can be extra switches between the host-attached switch and the first router in the network 🧩 In these cases, extra issues can pop up that affect SAVI operations 😵 If the bridging topologies connecting the switches change, or if the Link Aggregation Control Protocol (LACP) [IEEE802.1AX], the Virtual Router Redundancy Protocol (VRRP), or link management operations change which links are used to deliver traffic, the switch may need to move the SAVI state to a different port. The state may also need to be moved or re-established on a different switch 🔄
4.1.3. Upstream Routers 🛣️
Past the first-hop router, subsequent routers may also filter traffic from downstream networks 🚦 Since these routers don't have access to the link-layer address of the device the datagram was sent from, they can only confirm that the source IP address is within a prefix that's appropriate for the downstream router the datagram was received from 🫤
You've got options here, like simple access lists or Unicast Reverse Path Forwarding (uRPF). Access lists are generally only appropriate for the simplest cases, since managing them can be a headache 😩 Strict uRPF accepts the source address on a datagram if and only if it comes from a direction that would make sense for sending a datagram to that address, which means the filter is derived from routing information 🧭 These filtering procedures are discussed in more detail in [RFC3704] 📚
In lots of cases, this router knows which IP prefixes are supposed to be used on a given subnet 🤓 That might be because it delegated the prefix through DHCP or monitored a delegation like that. It may have advertised the 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 allows it, the router can enforce that hosts use these prefixes 🙌
4.1.4. ISP Edge PE Router 🌐
An obvious special case is an ISP PE router, where it gives its customer access 💁♀️ BCP 38 specifically encourages ISPs to use ingress filtering to limit how often spoofed addresses show up in the network 🫶
The question the ISP has to answer for itself is how much it trusts its downstream network 🤨 A contract might be written between an ISP and its customer requiring the customer to apply network ingress filtering procedures to the customer's own network, but there's no way upstream networks would be able to validate that 🙃
On the flip side, 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 done on the full address, which makes a lot of issues way simpler 🥹✨
4.1.5. ISP NNI Router to ISP NNI Router
okay so everything we said about customer networks? it totally applies to neighboring ISPs too 💅 two companies could sign an interconnection agreement saying network ingress filtering policy has to be implemented on all customer connections 📜. ISPs might then mark datagrams from neighbors that don't sign that contract, or don't actually behave like they did, as 'untrusted' 🚩. Or the ISP could toss untrusted prefixes into a separate BGP community [RFC4271] and use that to advertise the trust level to its BGP peers 🦋. bestie, that's giving organized.
Here's the tea: uRPF is less effective as a validation tool here because of asymmetric routing 😬. BUT when you can show spoofed addresses are actually present, the procedure can still be applied ✨.
The complication is kind of a big deal 🥺. In the abstract, it's super hard to know what addresses should show up in packets going from one ISP to another, so packet-level filtering and enforcement are really tough at this point in the network 💀. Whether you call it an NNI thing or a general property of the Internet, it's still a major factor you have to account for 🔥.
4.1.6. Cable Modem Subscriber Access
Cable Modem Termination Systems (CMTS) run Data Over Cable Service Interface Specification (DOCSIS) Media Access Control (MAC) domains 📡. They share some vibes with general switched networks (remember Section 4.1.1 above?) and some vibes with DSL access networks (see Section 4.1.7 below) 🧚. They also usually come with their own provisioning and monitoring tools, which might tackle some of the issues we talked about 🛠️.
4.1.7. DSL Subscriber Access
DSL subscriber access can be bridged or routed as far as the service provider's device is concerned 🌐, but generally the protocols carry enough info to check which subscriber is sending packets 🕵️♀️. So to stop one DSL subscriber from spoofing another, enforcement can usually happen at the aggregation router 💖. This holds even when there's a bridged infrastructure among subscribers, because DSL access generally requires all subscriber traffic to go through the access aggregation router 🫶.
If you want spoofing protection among devices inside a residence, that has to come from the CPE device, since the ISP's router doesn't have enough visibility to do it 🏠. It's not clear right now whether this problem is seen as a relevant threat 🤷♀️.
4.2. Currently Available Tools
There's a bunch of tools that have been developed, and that have seen some deployment, for dealing with these attacks 🧰.
4.2.1. BCP 38
If BCP 38 [RFC2827] is implemented in LAN segments, it's typically done on subnetwork boundaries, and traditionally it only deals with network-layer ingress filtering policies 🧱. The result: hosts in the segment can't spoof packets from address space outside the local segment itself 🙅♀️. BUT they can still spoof packets using source addresses that exist within the local network segment 😭.
4.2.2. Unicast RPF
Unicast RPF is a crude mechanism (lol, honest) that automates defining BCP 38 style filters based on routing table information 🤖. Its applicability parallels BCP 38's, although deployment caveats exist, as outlined in [RFC3704] 📝.
4.2.3. Port-Based Address Binding
Much of the early work of SAVI is aimed at minimizing source address spoofing in the LAN 🎯. Specifically, if mechanisms can be defined to configure port binding info for IP (to a port, to an unchangeable or authenticated MAC address, or to other credentials in the packet, so that an impostor can't create the needed values), then a big chunk of the spoofing threat space in the LAN can be marginalized 🙌.
Setting up this binding isn't trivial 😤, and it varies across both topology types and address allocation mechanisms 🌀.
4.2.3.1. Manual Binding
Binding a single link-layer and network-layer address to a port might seem totally trivial at first 🙃. But two main areas can complicate things: topologies where more than one 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 🤯. Also, if one or more dynamic address allocation mechanisms like DHCP are employed, some mechanism has to exist to associate those IP-layer addresses with the right link-layer ports as addresses get 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 paired with filtering policies that control which hosts can originate DHCP replies 🚦. Under those circumstances, SAVI switches can treat DHCP replies as authoritative sources of IP address binding info 👑. By eavesdropping on the DHCP exchanges, the SAVI switch can create the bindings it needs for address usage enforcement 👀.
For IPv6, there are two common automated address assignment techniques ✨. There are lots of variations and details, but for understanding the threats and basic responses, they're Stateless Address Autoconfiguration (SLAAC) and DHCP-based IPv6 address assignment 🧠. For DHCP-based IPv6 address assignment, the techniques above apply and are 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 lets the switches make sure only properly claimed IP addresses are used for data traffic 🛡️. It does not enforce that these addresses are assigned to the hosts, since SLAAC doesn't have a notion of address assignment 🙈.
4.2.3.3. IEEE 802.1x
IEEE 802.1x is an authentication protocol that lets a network figure out the identity of a user trying to join, then apply authorization rules to permit or deny the action 🔐. But by themselves, these tools only confirm that the user is authorized to use the network 🪪; they don't enforce what IP address the user is allowed to use 🚫.
It's 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 🔒. But lots of apps today either don't or can't use cryptographic authentication and protection mechanisms 😩. ARP for IPv4 doesn't use such protection 🙅. Secure Neighbor Discovery (SEND) does provide such protection for the IPv6 ND protocol, but SEND isn't widely used to date 🥲. Usage of such techniques is outside the scope of this document 📌.
While DNSSEC will significantly help protect DNS from the effects of spoof-based poisoning attacks, that protection doesn't help the rest of the network from spoofed attacks 🌸.
4.2.5. Residual Attacks
It's important to get that not every combo of network, service, and enforcement choices gives you a protectable network 🚧. For example, if you use conventional SLAAC in a switched network but only try to provide address enforcement on the routers, your ability to protect things is severely limited 💀.
5. Topological Challenges Facing SAVI ✨
As noted before, topological components and address allocation mechanisms really shape what's feasible for link-layer address and IP address port bindings 🗺️. The next sections talk about some of the 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 🗂️. But most networks (especially the ones with actual human users) are way more dynamic 🌊. So mechanisms that provide port-MAC-IP bindings need to accommodate dynamic address allocation schemes enabled by protocols like DHCP, DHCPv6 for address allocation, and IPv6 Stateless Address Autoconfiguration 🔄.
5.2. LAN Devices with Multiple Addresses
From the network topology point of view, think about hosts connected to switch ports that may have one or more IP addresses, plus devices that forward packets from other network segments 🕸️. It's way harder to enforce port-MAC-IP bindings on traffic from these hosts and devices than from more simply connected devices 😵.
5.2.1. Routers
Routers are the most obvious examples of devices where port-MAC-IP bindings are a problem 🛣️. They not only originate packets themselves and often have multiple interfaces, they also forward packets from other network segments 📦. So it's hard to set up port-MAC-IP binding rules ahead of time, because many addresses and IP subnets will probably need to be associated with the port-MAC in question 🤯.
5.2.2. NATs
Validating traffic from prefix-based and multi-address NATs is also a problem, for the same reasons as routers 🔁. Since 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 complicating example is 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's essentially a physical switch inside the blade server 🖥️. That's feasible, but it creates some complexity for figuring out where enforcement logic can or should live 🤔.
Logically distinct hosts, like the ones many kinds of virtualization logic provide, end up as a single physical host connected to a single port on the Ethernet switch in the topology, but actually having multiple internal virtual machines 💻. Each virtual machine may have its own IP and MAC addresses. These are connected by what's essentially (or sometimes literally) an internal LAN switch 🔌. That 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, but such enforcement can't 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 🚚. That 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 🧚.
5.2.4. Multi-LAN Hosts 🌈
Okay, so multi-interface hosts are a whole mood 💅, especially the ones that are multihomed and can forward packets from any of a bunch of source addresses. These can be problematic too 😭. Picture this: a port-MAC-IP binding gets made on each interface, and then a loopback IP or the address of a third interface shows up as the source address of a packet going out through an interface whose binding doesn't cover it. Bestie, that traffic can get discarded 💀. Static configuration of port-MAC-IP bindings can handle this scenario 🫶, but you need some a priori knowledge of address assignment and topology first, so it's not totally plug-and-play.
Now, it's rare to use loopback addressing or to send packets out one interface with another interface's source address 🙈. But these rarities do legitimately happen! Some servers, especially ones running underlying virtualization, use loopback techniques for management 🧚.
5.2.5. Firewalls 🔥
Firewalls that forward packets from other network segments, or that act as a source for locally originated packets, deal with the same issues as routers 💅. Same drama, different outfit 👑.
5.2.6. Mobile IP 🦋
Mobile IP hosts, in both IPv4 and IPv6, are proper members of the site they're currently in ✨. Their care-of address is a properly assigned address on the link they're using, and their packets get sent and received using that address 💖. So honestly? They don't add any extra complications, no cap 🙌.
Fun fact 🍓: at one point, people considered letting mobile hosts use their home address while they were away. That idea was never done, and the whole reason is to make sure 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 a little more iconic 👑. They're (typically) fixed devices, but they're 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 an HA handles are actually addressed to or from the link the HA sits on, it's probably best to think of it as a router, with a virtual interface to the actual hosts it serves 💜. So if the Mobile IP HA is trusted, it can do its own IP source address checking on the packets it forwards for mobile nodes 🔥. It can use the bindings established by the Mobile IP registration mechanisms to do that ✨.
5.2.7. Other Topologies 🌸
Any topology where a device connected to a switch port might forward packets with more than one source address for a packet it originated could be problematic 💀. Also, address allocation schemes bring their own considerations when you're looking at the solution space for a given SAVI solution 🧚.
5.3. IPv6 Considerations 💖
IPv6 brings in extra capabilities that indirectly complicate the spoofing analysis 🤔. It introduces and recommends SLAAC [RFC4862] ✨. With SLAAC, a host figures out its IP prefix, picks an Interface Identifier (IID), and then just starts communicating, which is so smooth 🦋. There are lots of advantages to this, but the lack of control interactions makes behavioral enforcement way harder 😭.
Then there's the very large IID space 🌌. That 64-bit IID space has a ton of upsides and opens the door to many useful behaviors 💅. But it also means that, without controls, hosts can mint anonymous addresses as often as they like (modulo the idiosyncrasies of the duplicate address procedure) 🙈. Like a lot of things, it's a feature for some purposes and a problem for others 🫠. For example, without claiming the entire IID space, an on-link attacker could generate enough IP addresses to fill up the Neighbor Discovery table space of the other Layer 3 (L3) devices on the link, including switches that monitor L3 behavior 💀. That could seriously mess 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 lets a site hit several valuable goals ✨. It's likely that, for many site topologies and policies, full source spoofing protection isn't possible 🥲. But for lots of sites, there are steps that can be taken that still provide benefit 💖.
One big class of benefit is masquerade prevention 🎭. Security threats where one machine pretends to be another (say, to hijack an apparently secure session) can happen inside a site and do real damage 😬. Having mechanisms where host-facing devices prevent this is a major intra-site security upgrade 🔥. Security experts report that most security breaches are internal, so this can be super valuable 👑. One example: these techniques should help mitigate internal attacks on the site routing system 🧚.
A second class of benefit ties into the traceability described above 🕵️♀️. When a security incident gets detected, whether inside the site or outside (and traced back to the site), it can be critical to figure out the actual source 😭. If address usage can be tied to the kinds of anchors described earlier, that helps with responding to incidents 💜.
Beyond these local benefits, there can be more global ones too 🌍. If address usage is tied to anchors, it may become possible to prevent or control the use of large numbers of anonymous IPv6 addresses for attacks, or at least trace even those attacks back to their source 🦋.
As the security considerations below explain, these operational behaviors need to be weighed against the reduction in user privacy that's implied if you log traffic bindings 🙈. Beyond the architectural trade-offs, the network administrator has to plan for handling this privacy-sensitive info about their users responsibly 🫶.
7. Security Considerations 🛡️
This document gives limited discussion of some security threats that source address validation improvements will help mitigate 💅. It's not meant to be all-inclusive, whether you look at it from a threat analysis perspective or from the source address validation application side 🤓.
It's so tempting to think SAVI solutions let you use this tech to trace a datagram back to the person, or at least the end system, that sent it 😭. But for several reasons, the technology can only be used to derive circumstantial evidence, and it doesn't actually solve that problem 💀.
At the Internet layer, the source address of a datagram should be the address of the system that originated it, and it's where any reply is expected to go 📬. But systems fall into a few broad categories 🌈. Many are single-user systems, like 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. They just relay messages or perform services on behalf of users of other systems (for example, SMTP and peer-to-peer file sharing) 🧚.
Here's the spicy part 🌶️: even if every Internet-connected network implements source address validation at the ultimate network ingress, and there are assurances that intermediate devices never modify datagram source addresses, source addresses still cannot be used as an authentication mechanism 💀. The only techniques that unquestionably validate the 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 for network administrators to consider is an inside attack that probes the network for spoofing modes that can be pulled off 🕵️♀️. If the probes are run below alarm thresholds, an internal attacker might safely figure out which spoof modes they can use 😱. So these techniques have to be managed in a way that avoids giving the network administrator a false sense of security 🫠.
7.1. Privacy Considerations 🔒
It's important to understand that enforcing and recording IP address bindings has privacy implications 👀. In some circumstances, this binding data may count as personally identifying information 💜. In general, collecting private info about users brings ethical and legal responsibilities for the network administrator ⚖️.
Because of this, collection and retention of logged binding information need to be thought through carefully 🧐. Preventing spoofing doesn't by itself require that kind of retention 🙌. Analysis of immediate events may rely on having logs of current bindings, though 🔍. So privacy issues can be eased by removing binding logs after the binding lifetimes expire ✨. Logs of apparent spoof attempts are a separate matter, and they may need longer retention to spot patterns of deliberate or accidental abuse 🕸️.
With the operations described here, the network administrator is collecting info about where on the network the user is active 📍. The recorded bindings also supplement the address usage info about users that's available from DHCP logs 📋. For example, if IPv6 SLAAC is in use and IP to Layer 2 address bindings are being logged, the administrator can associate users with their IP addresses even when IPv6 privacy addresses are used 😳.
On top of this, you have to be careful about attributing actions to users based on this kind of info 🧠. No matter how strong the tools are in theory, administrators should always allow for the possibility that the information is wrong, and they 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 attribution evaluation also needs to allow for those cases 🌍.
8. Acknowledgments 🫶
A portion of the primer text in this document came directly from [SAVA], which was authored by Fred Baker and Ralph Droms 📝. Huge thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola for contributing text and doing 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.That's the whole reference list, babe! 🌈✨
9.2. Informative References ✨
Okay, bestie, now we're in the "extra reading" section 📚 These references aren't required to implement anything, but they're super useful for the deeper background.
[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. 💅[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
And that's the whole spec, bestie 🎀🦋 We made it through all six parts. Go be a main character in your implementation 👑💖
📦 where this page comes from
- ietf: rfc6959 2013-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms