RFC 7039

RFC 7039: Source Address Validation Improvement (SAVI) Framework 💖

Okay bestie, this is RFC 7039 🎀, the Source Address Validation Improvement (SAVI) Framework. It's dated October 2013 and it's Informational, so it's not a standards-track spec, just a published explainer 🦋. The authors are J. Wu and J. Bi (Tsinghua Univ.), M. Bagnulo (UC3M), F. Baker (Cisco), and C. Vogt (Ed.) ✨. It's published under ISSN 2070-1721, and the title block doesn't list anything it obsoletes or updates 🌸.

Abstract ✨

Okay so SAVI methods were built to stop nodes on the same IP link from spoofing each other's IP addresses 🙈. The goal is to team up with ingress filtering and give us finer-grained, standardized IP source address validation 💅. This doc is a framework doc, which means it explains and motivates how the SAVI methods are designed. The specific SAVI methods get their own documents, so this one is the big-picture vibe check 🧚.

Status of This Memo

Let's be clear: this document is not an Internet Standards Track specification. It's published just for informational purposes 📚.

It's a product of the IETF, it reflects the consensus of the IETF community, it got public review, and the IESG approved it for publication 🫶. Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

Info about this doc's current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7039 💜.

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, which you can find at http://trustee.ietf.org/license-info as in effect on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 📜. Any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥.

This document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Deployment Options  . . . . . . . . . . . . . . . . . . . . .   5
  3.1.  IP Address Assignment Methods . . . . . . . . . . . . . .   6
  3.2.  Binding Anchors . . . . . . . . . . . . . . . . . . . . .   6
4.  Scalability Optimizations . . . . . . . . . . . . . . . . . .   7
5.  Reliability Optimizations . . . . . . . . . . . . . . . . . .   9
6.  Scenario with Multiple Assignment Methods . . . . . . . . . .  10
7.  Prefix Configuration  . . . . . . . . . . . . . . . . . . . .  10
8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
  10.2.  Informative References . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

Okay, so IP source addresses are how hosts and network gear figure out where a packet came from, and it's also where return data gets sent 📬. That means spoofing them can lead to impersonation, hiding your tracks, and shady traffic redirection 💀. The sad part is the Internet architecture doesn't stop IP source address spoofing [RFC6959] 😭. And since the source address usually plays no role in getting a packet forwarded, the sending host can pick whatever it wants without breaking delivery 🙃. So we need extra methods for source address validation that add an explicit check on whether a packet's source address is legit, on top of forwarding 🔍.

Source address validation can happen at different levels of detail 💅. Ingress filtering [BCP38] [BCP84] is the widely deployed standard for this, and it works at the coarse level of whole networks. It checks that the prefix of a packet's source address routes back to the network it came in on 🛣️. The big perk is simplicity: the accept-or-reject call can be made purely from what routing protocols already know 🧠. The catch is that all that routing info is aggregated, so you can't validate at a finer granularity 😤. Finer-grained validation would keep source address info accurate, make denial-of-service attacks harder to pull off, and help localize hosts and spot misbehaving ones 🕵️‍♀️. There are partial solutions [BA2007] for finer-grained validation, but they're proprietary, so they're often a no-go for corporate procurement 💼.

The Source Address Validation Improvement (SAVI) method was built to complement ingress filtering with standardized validation at the most fine-grained level possible, which is individual IP addresses 🦋. It stops hosts on the same link from spoofing each other's addresses 🛑. To make it easy to deploy across all sorts of networks, SAVI was designed to be modular and extensible 🧩. This document describes and motivates that design 💖.

Heads up that SAVI brings up some important privacy considerations, which are covered more fully in [RFC6959] 🔐. SAVI implementers must take those privacy considerations into account when designing solutions that match this framework, and they should follow the recommendations given in [RFC6959] 🫶.

2. Model 🌸

So network operators can deploy fine-grained source address validation without needing any help from the hosts, SAVI was designed to be purely network based 🌐. A SAVI instance enforces legit source address use by hosts using this three-step model:

1. Figure out which IP source addresses are legitimate for a host, based on monitoring the packets that host exchanges.
2. Bind a legitimate IP address to a link-layer property of the host's network attachment. This property, called a "binding anchor", must be verifiable in every packet the host sends, and it has to be harder to spoof than the host's IP source address itself 🔒.
3. Enforce that the IP source addresses in packets match the binding anchors they were bound to ✅.

This model means a SAVI instance (SAVI functionality) can live anywhere on the link the hosts attach to, so there are different places it can go 🗺️. One option is the hosts' default router. In that setup, source addresses get validated for packets going through the default router, but packets exchanged locally on the link may skip validation 🙈. Another option is a switch between the hosts and their default router. Then packets can get validated even when they're exchanged locally on the link 🎀.

The closer a SAVI instance sits to the host, the better the SAVI method works 💯. That's because each of the three steps is easiest to do near the host:

• Figuring out a host's legit source addresses is most efficient close to the host, since the chance that the host's packets sneak past a SAVI instance (and can't be monitored) goes up with the topological distance between them 👀.
• Picking a binding anchor for a host's source address is easiest close to the host, since lots of link-layer properties are only unique for a given host on the link segment directly attached to it 🔗.
• Enforcing legit source address use is most reliable close to the host, since the chance that packets bypass the SAVI instance (and so skip validation) also goes up with distance 📏.

So the preferred spot for SAVI instances is close to hosts, like in switches that directly attach to the hosts whose addresses are being validated 🏠.

That said, SAVI mechanisms should also be able to handle cases where hosts aren't directly attached to the SAVI-capable device 🤷‍♀️. For example, deployments might mix SAVI-capable switches with legacy switches. In general, a SAVI solution needs to spell out how it handles a bunch of deployment scenarios and weird edge cases, like working with legacy devices, hosts moving between wireless attachment points, network partitions, and more 🌪️.

Also, with legacy switches the security level is lower, because the hosts connected to the legacy server don't get full protection 😬.

3. Deployment Options 🎀

The SAVI model from Section 2 depends on deployment in two specific ways 🧠:

• Figuring out legit IP source addresses depends on the IP address assignment method in use on a link, since a host only becomes the legit user of an address through that assignment 📋.
• Binding anchors depend on the technology used to build the link they're used on, because they're link-layer properties of a host's network attachment 🔌.

To make SAVI easy to deploy across all kinds of networks, it's designed to support different IP address assignment methods and to work with different binding anchors 🌈. Obviously, both the assignment methods used on a link and the binding anchors available affect how well source address validation works and how strong it is 💪. The next two subsections break down that impact and show how SAVI deals with it.

Part 2 is coming up next, so stay tuned, bestie 🦋💖

3.1. IP Address Assignment Methods ✨

okay so SAVI works by tracing IP address assignment packets, which means it has to understand the rules of each specific assignment method 🧚. But one variant per method isn't enough, bestie, because a single link can run several methods at the same time 😭. So the SAVI method comes in multiple variants: one for DHCP [RFC2131] [RFC3315], one for Stateless Address Autoconfiguration (SLAAC) [RFC4862] with or without Secure Neighbor Discovery (SEND) [RFC3971], one for Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] [RFC5739] [RFC5026], and combos of all of those 💖.

So why bother with single-method variants when there's already one that handles everything? Simplicity 🎀. A lot of links today either use just one method or, from SAVI's point of view (which is the same thing), use different methods for different prefixes 🌸. A SAVI method for those links can be simpler than one for links with several methods per prefix, and that's the whole point ✨.

3.2. Binding Anchors

The SAVI method supports a whole range of binding anchors 🦋:

• The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's interface.
• The port on an Ethernet switch to which a host attaches.
• The security association between a host and the base station on wireless links.
• The combination of a host interface's link-layer address and a customer relationship in cable modem networks.
• An ATM virtual channel, a PPP session identifier, or a Layer 2 Tunneling Protocol (L2TP) session identifier in a DSL network.
• A tunnel that connects to a single host, such as an IP-in-IP tunnel, a Generic Routing Encapsulation (GRE) tunnel, or an MPLS label-switched path.

Not all of these are equally secure, and that's kind of a big deal 🙈. IEEE extended unique identifiers, for example, don't make a secure binding anchor, because they can be spoofed with very little effort 💀. Switch ports alone might not be enough either, since one port can lead to more than one host, like with concatenated switches.

Given all that variety, you could define a set of possible binding anchors and let the administrator pick one or more 💅. But that choice would have to come with an explanation of the pros and cons of each option, obviously 🤓. SAVI devices may also have a default binding anchor depending on the lower layers. That default could be switch ports when they're available and MAC addresses otherwise, or it could be MAC addresses plus switch ports in addition, if available ✨.

4. Scalability Optimizations 🌈

Putting a SAVI instance close to hosts means multiple SAVI instances have to be able to coexist so big links can be supported 🧚. The model of the SAVI method doesn't depend on how many instances there are per link, but if they coexist without any extra measures, they can end up needing more memory than necessary 😭. A SAVI instance creates bindings for the IP source addresses of all hosts on a link, so when several instances share a link, those bindings get replicated. More memory means a more expensive instance, and that's especially a problem for instances on a switch, since it can really bump up the cost of that switch 💸.

To cut memory use for SAVI instances on a switch, the SAVI method lets you turn off binding replication on links with multiple SAVI instances 🎀. This takes manual disabling of IP source address validation on the switch ports that connect to other switches running a SAVI instance. Each SAVI instance then only validates IP source addresses on the ports where hosts attach, either directly or through switches without a SAVI instance. Ports facing other SAVI switches don't validate anything. The switches running SAVI instances end up forming a "protection perimeter" 🛡️. Source addresses in packets crossing the perimeter get validated by the ingress SAVI instance, and no further validation happens while those packets stay within the perimeter or leave it.

                                                 ..............
                       protection perimeter -->  : +--------+ :
          +---+  +---+                           : |  SAVI  | :
          | A |  | B |  <-- hosts                : | switch | :
          +---+  +---+                           : +--------+ :
         ...|......|.............................:        |   :
         : +--------+          +--------+          +--------+ :
         : |  SAVI  |----------| legacy |          |  SAVI  | :
         : | switch |          | switch |----------| switch | :
         : +--------+          +--------+          +--------+ :
         :   |        ...............................|........:
         : +--------+ :                            +--------+
         : |  SAVI  | :                            | legacy |
         : | switch | :                            | switch |
         : +--------+ :                            +--------+
         :............:                             |      |
                                                  +---+  +---+
                                       hosts -->  | C |  | D |
                                                  +---+  +---+

Figure 1: Protection Perimeter Concept

Figure 1 shows the protection perimeter idea in action 👀. There's a link with six switches, and four of them, labeled "SAVI switch", run a SAVI instance. The protection perimeter those four SAVI instances create is drawn as a dotted line. IP source address validation is turned on for every switch port on the perimeter and turned off for all the other switch ports. Four hosts, A through D, attach to the perimeter.

In the Figure 1 example, the protection perimeter includes one of the legacy switches, the one sitting in the middle of the link topology 🙌. That's what makes one single, unpartitioned protection perimeter possible. One big perimeter is great for memory, since every binding is kept only once, by the SAVI instance attached to the host being validated 🧠. If you left that legacy switch out, you'd get two smaller perimeters, one to the left and one to the right of the topology 😬. Memory use would go up then: IP source address validation would be switched on at the two ports connecting to the legacy switch, so the SAVI instances next to the legacy switch would each replicate all the bindings from the other perimeter. The legacy switch can be part of the perimeter here because this topology guarantees that packets can't enter the perimeter through it. Without that guarantee, the legacy switch would have to stay out of the perimeter so that packets entering the perimeter still get IP source address validation 🔒.

Note that if this kind of configuration is used, care must be taken, because any hosts on subnets attached to non-enforcing ports will be able to use spoofed source addresses. 🚨

5. Reliability Optimizations 🫶

Bindings are stored explicitly as the legitimate IP addresses, so if a binding fails to get created, or gets removed too early, legitimate packets can get lost 😭. That can happen in three situations:

• Legitimate IP address configuration packets, which should trigger the creation of a binding in a SAVI instance, get lost before they reach the SAVI instance.
• A SAVI instance loses a binding, for example, because it restarted.
• The link topology changes, so hosts end up communicating through SAVI instances that don't have a binding for those hosts' IP addresses.

To limit the damage from missing bindings for legitimate IP addresses, the SAVI method includes a mechanism for reactive binding creation based on regular packets 🦋. It supplements the proactive binding creation that's based on IP address configuration packets. Reactive binding creation kicks in when a SAVI instance notices excessive drops of regular packets coming from the same IP address. The SAVI instance then checks whether that IP address is unique on the link. How that check works depends on the IP address configuration method the SAVI instance supports. The SAVI method variant for Stateless Address Autoconfiguration and for Secure Neighbor Discovery verifies an IP address through the Duplicate Address Detection procedure 🔍. The SAVI method variant for DHCP verifies an IP address through a DHCP Lease Query message exchange with the DHCP server 📬. If the verification shows the IP address is unique on the link, the SAVI instance creates a binding for it. Otherwise, no binding gets created, and packets sent from that IP address keep getting dropped 🙅‍♀️. These reliability issues should be addressed in all the SAVI protocols that describe particular SAVI methods 💜.

6. Scenario with Multiple Assignment Methods 🧚

Multiple assignment methods can be used on the same link, which means the SAVI device might have to deal with a mix of binding discovery methods 🌈. If each assignment method uses a different address prefix, the "mix scenario" behaves the same as the scenario with only one assignment method ✨. But if different assignment methods are used to assign addresses from the same prefix, you need extra thinking, because one binding mechanism can create a binding that violates an existing binding from another mechanism 😬. For example, a binding from First-Come, First-Served (FCFS) SAVI [RFC6620] may violate a binding from SAVI-DHCP [SAVI-DHCP]. So collisions between different SAVI mechanisms in the mix scenario have to be handled whenever more than one assignment method is used to assign addresses from the same prefix 🛠️.

The prioritization of relationships between different assignment methods is the basis for resolving those possible collisions 👑. The standard documents for the assignment methods (DHCP [RFC2131], DHCPv6 [RFC3315], SLAAC [RFC4862], and SEND [RFC3971]) already imply a prioritization relationship in general cases 📚. But in some scenarios, that default prioritization level might not quite fit 🤷‍♀️. So a configurable prioritization level should be supported in the SAVI solution for the mix scenario [SAVI-MIX] 💖.

7. Prefix Configuration 🎀

okay so before you set up a host-level granularity binding, you NEED the right prefixes configured on the SAVI device 💅 it's giving foundation. This doc suggests a set of 3 prefix configuration mechanisms at a SAVI device:

• Manual Prefix Configuration: the allowed prefix scope of IPv4 addresses, IPv6 static addresses, IPv6 addresses assigned by Stateless Address Autoconfiguration (SLAAC), and IPv6 addresses assigned by DHCPv6 can be set by hand on the SAVI device. FE80::/64 is always a feasible prefix in IPv6 🌸
• Prefix Configuration by Router Advertisement (RA) Snooping: the allowed prefix scope of IPv6 static addresses and IPv6 addresses assigned by SLAAC can be set on the SAVI device by snooping an RA message there 👀
• Prefix Configuration by DHCP Prefix Delegation (DHCP-PD) Snooping: the allowed prefix scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, and IPv6 addresses assigned by DHCPv6 can be set by snooping a DHCP-PD message at the SAVI device 🦋

If some of the prefix scopes are set to have no prefix, that means the matching address assignment method is not allowed in the network. Lowkey a very strict vibe 🙈

There's no need to explicitly present these prefix scopes, but these restrictions should be used as the premier check in binding setup ✨

⚠️ bestie, when SAVI is only partially deployed, binding may fail, because RA messages and DHCP-PD can be spoofed 😭 So it is recommended that Manual Prefix Configuration be used unless SAVI gets fully deployed. Protect yourself 🫶

8. Acknowledgments 🌈

The authors want to thank the SAVI working group for a thorough technical discussion on the design and framework of the SAVI method as captured in this document, especially Erik Nordmark, Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia 💜 Thanks also to Torben Melsen for reviewing this document 🫶

9. Security Considerations 💀

Okay, this section is serious, so buckle up 😭

This document only discusses possible methods to mitigate the usage of forged IP addresses. Some of those methods may rely on cryptographic methods, but not all do. As a result, it is generally not possible to prove address ownership in any strong sense. If a binding anchor is not exclusive for each IP address, or is without strong security, addresses can still be forged. Besides, the binding may not accord with the address management requirement, which can be more specified for each client. However, given that no new protocol is introduced, the improvements are still acceptable. If strong security is required when using IP addresses, then cryptographic-based authentication must be used, as it is the only way to provide strong security 🔥

Section 2 explains how the preferred location of SAVI instances is close to hosts. However, in some cases, this makes the SAVI instances themselves vulnerable and may defeat the purpose of deploying a SAVI solution 😱 For instance, deployments should not place SAVI functionality in devices that are physically exposed. Even if the device correctly monitors the source address usage of hosts, an attacker could replace the device with one that does not check, or that does not hook up to a trusted interface from the device to the rest of the network 🚨 Similarly, deployments where SAVI instances are distributed across administrative boundaries are not recommended. For instance, in most cases it would be undesirable to deploy a distributed SAVI solution on both sides of a customer-provider interface if the solution required trusting the correct operation of the SAVI devices on the other side of the interface 🙅‍♀️

10. References 📚

10.1. Normative References 💖

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

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

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

[RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            Address Autoconfiguration", RFC 4862, September 2007.

[RFC5026]   Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
            Bootstrapping in Split Scenario", RFC 5026, October 2007.

[RFC5739]   Eronen, P., Laganier, J., and C. Madson, "IPv6
            Configuration in Internet Key Exchange Protocol Version 2
            (IKEv2)", RFC 5739, February 2010.

[RFC5996]   Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
            "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
            5996, September 2010.

[RFC6620]   Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
            SAVI: First-Come, First-Served Source Address Validation
            Improvement for Locally Assigned IPv6 Addresses", RFC
            6620, May 2012.

[RFC6959]   McPherson, D., Baker, F., and J. Halpern, "Source Address
            Validation Improvement (SAVI) Threat Scope", RFC 6959,
            May 2013.

10.2. Informative References 🧚

[BA2007]    Baker, F., "Cisco IP Version 4 Source Guard", Work in
            Progress, November 2007.

[BCP38]     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.

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

[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
            DHCP", Work in Progress, June 2013.

[SAVI-MIX]  Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI
            for Mixed Address Assignment Methods Scenario", Work in
            Progress, May 2013.

Authors' Addresses 🎀

Jianping Wu
Tsinghua University
Computer Science, Tsinghua University
Beijing  100084
China

EMail: jianping@cernet.edu.cn


Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing  100084
China

EMail: junbi@tsinghua.edu.cn


Marcelo Bagnulo
Universidad Carlos III de Madrid
Avenida de la Universidad 30
Leganes, Madrid  28911
Spain

EMail: marcelo@it.uc3m.es


Fred Baker
Cisco Systems
Santa Barbara, CA  93117
United States

EMail: fred@cisco.com


Christian Vogt (editor)
3507 Palmilla Drive
San Jose, CA  95134
United States

EMail: mail@christianvogt.net

---

That's the whole thing, bestie 🌈✨ You made it through all of RFC 7039! 👑