| Internet-Draft | Intra-domain SAVNET Problem Statement | February 2025 |
| Li, et al. | Expires 25 August 2025 | [Page] |
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 August 2025.¶
Copyright (c) 2025 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Source Address Validation (SAV) is important for defending against source address spoofing attacks. Since it is unrealistic to expect any single SAV mechanism to be universally supported, a multiple-fence architecture called Source Address Validation Architecture (SAVA) allows for implementing SAV at multiple levels: access-network SAV, intra-domain SAV, and inter-domain SAV (See [RFC5210]). The "domain" used in this document means the Autonomous System (AS). Access-network SAV (e.g., SAVI [RFC7039], IP Source Guard (IPSG) [IPSG], and Cable Source-Verify [cable-verify]) is deployed inside access networks to ensure the host inside the access network cannot use the source address of another host (See [RFC5210]). When access-network SAV is not universally deployed, intra-domain SAV and inter-domain SAV on routers can help block spoofing traffic as close to the source as possible.¶
This document focuses only on the analysis of intra-domain SAV. Unlike inter-domain SAV which requires information (e.g., Border Gateway Protocol (BGP) data) provided by other ASes to determine SAV rules, intra-domain SAV for an AS determines SAV rules solely by the AS itself without communication with other ASes. Intra-domain SAV for an AS aims at achieving two goals: i) blocking source-spoofed packets originated from its host networks or customer networks using a source address of other networks; and ii) blocking source-spoofed packets coming from other ASes using a source address of this AS.¶
Figure 1 illustrates the goals and function of intra-domain SAV with two cases. Case i shows that the host network or customer network of AS X originates source-spoofed packets using a source address of other networks. If AS X deploys intra-domain SAV, the spoofed packets can be blocked by host-facing routers or customer-facing routers of AS X (i.e., Goal i). Case ii shows that AS X receives source-spoofed packets using a source address of AS X from other ASes (e.g., AS Y). If AS X deploys intra-domain SAV, the spoofed packets from AS Y can be blocked by AS border routers of AS X (i.e., Goal ii).¶
Case i: The host network or customer network of AS X originates
packets spoofing source addresses of other networks
Goal i: If AS X deploys intra-domain SAV,
the spoofed packets can be blocked by AS X
Spoofed packets
using source addresses
+-------------------------------+ of other networks +------+
| Host/Customer Network of AS X |---------------------->| AS X |
+-------------------------------+ +------+
Case ii: AS X receives packets spoofing source addresses of AS X
from other ASes (e.g., AS Y)
Goal ii: If AS X deploys intra-domain SAV,
the spoofed packets can be blocked by AS X
Spoofed packets
using source addresses
+------+ of AS X +------+
| AS X |<----------------------| AS Y |
+------+ +------+
This document clarifies that the scope of SAV is to check the validity of the source address of data packets in IP-encapsulated scenarios including:¶
Native IP forwarding: including global routing table forwarding and VPN forwarding scenarios.¶
IP-encapsulated Tunnel (IPsec [RFC4301], GRE [RFC2784], SRv6 [RFC9256], etc.): focusing on the validation of the outer layer IP address.¶
Both IPv4 and IPv6 addresses.¶
SAV does not check non-IP packets in MPLS label-based forwarding and other non-IP-based forwarding scenarios.¶
In the following, this document provides a gap analysis of existing intra-domain SAV mechanisms, concludes key problems to solve, and proposes requirements for future ones.¶
SAV Rule: The rule in a router that describes the mapping relationship between a source address (prefix) and the valid incoming interface(s). It is used by a router to make SAV decisions.¶
Host Network: An intra-domain stub network that consists of hosts.¶
Host-facing Router: An intra-domain router facing a host network.¶
Customer Network: An intra-domain stub network that consists of hosts and routers.¶
Customer-facing Router: An intra-domain router facing a customer network.¶
Improper Block: The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules.¶
Improper Permit: The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules.¶
SAV-specific Information: The information specialized for SAV rule generation, which is exchanged among intra-domain routers.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section introduces existing intra-domain SAV mechanisms, including BCP38 [RFC2827] and BCP84 [RFC3704].¶
ACL-based ingress filtering or BCP38 [RFC2827] requires that network operators manually configure ACL rules on routers to block or permit data packets with specific source addresses. This mechanism can be used on interfaces of host-facing or customer-facing routers facing a host/customer network to prevent the corresponding host/customer network from spoofing source prefixes of other networks [manrs-antispoofing]. In addition, it is also usually used on interfaces of AS border routers facing an external AS to block data packets using disallowed source addresses, such as internal source addresses owned by the local AS [nist-rec]. In any application scenario, ACL rules must be updated in time to be consistent with the latest filtering criteria when the network changes.¶
Strict uRPF [RFC3704] is also typically used on interfaces of host-facing or customer-facing routers facing a host/customer network. Routers deploying strict uRPF accept a data packet only when i) the local FIB contains a prefix covering the packet's source address and ii) the corresponding outgoing interface for the prefix in the FIB matches the packet's incoming interface. Otherwise, the packet will be blocked.¶
Loose uRPF [RFC3704] uses a looser validation method. A packet will be accepted if the router's local FIB contains a prefix covering the packet's source address regardless of the interface from which the packet is received. In fact, interfaces of AS border routers facing an external AS may use loose uRPF to block incoming data packets using non-global addresses [nist-rec]. EFP-uRPF [RFC8704] is another SAV mechanism which can be used on AS border routers as well. This document does not analyze EFP-uRPF because it is an inter-domain SAV mechanism with a different goal from those described in Section 1.¶
Carrier Grade NAT has some operations on the source addresses of packets, but it is not an anti-spoofing tool, as described in [manrs-antispoofing]. If the source address of a packet is in the INSIDE access list, the NAT rule can translate the source address to an address in the pool OUTSIDE. The NAT rule cannot determine whether the source address is spoofed or not. In addition, the packet using a spoofed source address will still be forwarded if the spoofed source address is not included in the INSIDE access list. Therefore, Carrier Grade NAT cannot help identify and block source-spoofed data packets.¶
In summary, ACL-based ingress filtering and uRPF are the two most commonly used intra-domain SAV mechanisms. This document provides a gap analysis of these two mechanisms in Section 3.¶
This section elaborates the key problems of current intra-domain SAV on host-facing or customer-facing routers and intra-domain SAV on AS border routers, respectively.¶
Towards Goal i in Figure 1, intra-domain SAV is typically deployed on interfaces of host-facing or customer-facing routers facing an intra-domain host/customer network to validate data packets originated from that network, since SAV is more effective when deployed closer to the source. ACL-based ingress filtering and strict uRPF are commonly used for this purpose.¶
ACL rules must be manually updated according to prefix changes or topology changes in a timely manner. Otherwise, if ACL rules are not updated in time, improper block or improper permit problems may occur. To ensure the accuracy of ACL rules in dynamic networks, high operational overhead will be induced to achieve timely updates for ACL configurations.¶
Strict uRPF can generate and update SAV rules in an automatic way but it will cause improper blocks in the scenario of asymmetric routing or hidden prefix.¶
Figure 2 shows asymmetric routing in a multi-homing scenario. In the figure, Network 1 is a host/customer network of the AS. It owns prefix 2001:db8::/32 [RFC6890] and is attached to two intra-domain routers, i.e., Router 1 and Router 2. For the load balance purpose of traffic flowing to Network 1, Network 1 expects the incoming traffic destined for the sub-prefix 2001:db8:8000::/33 to come only from Router 1 and the incoming traffic destined for the other sub-prefix 2001:db8::/33 to come only from Router 2. To this end, Router 1 only learns the route to sub-prefix 2001:db8:8000::/33 from Network 1, while Router 2 only learns the route to the other sub-prefix 2001:db8::/33 from Network 1. Then, Router 1 and Router 2 distribute the sub-prefix information to routers in the AS through intra-domain routing protocols such as OSPF or IS-IS. The FIBs of Router 1 and Router 2 are shown in the figure.¶
Although Network 1 does not expect traffic destined for 2001:db8::/33 to come from Router 1, it may send traffic with source addresses of prefix 2001:db8::/33 to Router 1 for load balance of traffic originated from Network 1. As a result, there is asymmetric routing of data packets between Network 1 and Router 1. Arrows in the figure indicate the flowing direction of traffic. In addition to the traffic engineering mentioned above, other factors may also cause the similar asymmetric routing between host-facing/customer-facing routers and host/customer networks.¶
+---------------------------------------------------------+ | AS | | +----------+ | | | Router 3 | | | +----------+ | | / \ | | / \ | | / \ | | +----------+ +----------+ | | | Router 1 | | Router 2 | | | +-----+#+--+ +-+#+------+ | | /\ / | |Traffic with \ / Traffic with | |source IP addresses \ / destination IP addresses| |of 2001:db8::/33 \ \/ of 2001:db8::/33 | | +----------------+ | | | Host/Customer | | | | Network 1 | | | |(2001:db8::/32) | | | +----------------+ | | | +---------------------------------------------------------+ FIB of Router 1 FIB of Router 2 Dest Next_hop Dest Next_hop 2001:db8:8000::/33 Network 1 2001:db8:8000::/33 Router 3 2001:db8::/33 Router 3 2001:db8::/33 Network 1 The legitimate traffic originated from Network 1 with source IP addresses of 2001:db8::/33 will be improperly blocked by Router 1 if Router 1 uses strict uRPF.
If Router 1 uses strict uRPF on interface '#', the SAV rule is that Router 1 only accepts packets with source addresses of 2001:db8:8000::/33 from Network 1. Therefore, when Network 1 sends packets with source addresses of 2001:db8::/33 to Router 1, strict uRPF at Router 1 will improperly block these legitimate packets. Similarly, when Router 2 uses strict uRPF on its interface '#' and receives packets with source addresses of prefix 2001:db8:8000::/33 from Network 1, it will also improperly block these legitimate packets because strict uRPF at Router 2 will only accept packets from Network 1 using source addresses of prefix 2001:db8::/33.¶
Towards Goal ii in Figure 1, intra-domain SAV is typically deployed on interfaces of AS border routers facing an external AS to validate packets arriving from other ASes. Figure 4 shows an example of SAV on AS border routers. In the figure, Router 3 and Router 4 deploy intra-domain SAV on interface '#' for validating data packets coming from external ASes. ACL-based ingress filtering and loose uRPF are commonly used for this purpose.¶
Packets with + Packets with + spoofed P1/P2| spoofed P1/P2| +-------------|---------------------------|---------+ | AS \/ \/ | | +--+#+-----+ +---+#+----+ | | | Router 3 +---------------+ Router 4 | | | +----------+ +----+-----+ | | / \ | | | / \ | | | / \ | | | +----------+ +----------+ +----+-----+ | | | Router 1 | | Router 2 | | Router 5 | | | +----------+ +----------+ +----+-----+ | | \ / | | | \ / | | | \ / | | | +---------------+ +-------+-------+ | | | Customer | | Host | | | | Network | | Network | | | | (P1) | | (P2) | | | +---------------+ +---------------+ | | | +---------------------------------------------------+
By configuring ACL rules, data packets that use disallowed source addresses (e.g., non-global addresses or internal source addresses) can be blocked at AS border routers. However, the operational overhead of maintaining updated ACL rules will be extremely high when there are multiple AS border routers adopting SAV as shown in Figure 4.¶
As for loose uRPF, it sacrifices the directionality of SAV and has limited blocking capability, because it allows packets with source addresses that exist in the FIB table on all router interfaces.¶
As analyzed above, existing intra-domain SAV mechanisms have significant limitations on automatic update or accurate validation.¶
ACL-based ingress filtering relies on manual configurations and thus requires high operational overhead in dynamic networks. To guarantee accuracy of ACL-based SAV, network operators have to manually update the ACL-based filtering rules in time when the prefix or topology changes. Otherwise, improper block or improper permit problems may appear.¶
Strict uRPF can automatically update SAV rules, but may improperly block legitimate traffic under asymmetric routing scenario or hidden prefix scenario. It may mistakenly consider a valid incoming interface as invalid, resulting in improper block problems; or it may mistakenly consider an invalid incoming interface as valid, resulting in improper permit problems.¶
Loose uRPF is also an automated SAV mechanism but its SAV rules are overly loose. Most spoofed packets will be improperly permitted by loose uRPF.¶
In summary, uRPF cannot guarantee the accuracy of SAV because it solely uses the router’s local FIB or RIB information to determine SAV rules. A router cannot see the asymmetric route between itself and another router/network from its own perspective. As a result, strict uRPF has improper block problems in the scenario of asymmetric forwarding or asymmetric routing. The network operator has a comprehensive perspective so he/she can configure the correct SAV rules. However, manual configuration has limitations on automatic update.¶
This section lists the following five requirements and related discussions that should be considered when designing the new intra-domain SAV mechanism.¶
The new intra-domain SAV mechanism MUST improve the accuracy upon existing intra-domain SAV mechanisms. It MUST achieve the two goals described in Section 1 to prevent those spoofing traffic from flowing into the router network. Meanwhile, it MUST avoid blocking legitimate data packets, especially when there are asymmetric routes or network changes. This requires that routers exchange necessary information (i.e., SAV-specific information) to form a comprehensive perspective. By integrating SAV-specific information of other routers, routers will learn the asymmetric forwarding or routing behaviors and determine accurate SAV rules.¶
The new intra-domain SAV mechanism MUST be able to automatically generate and update SAV rules, rather than relying entirely on manual updates like ACL-based ingress filtering. Although manual configuration may still be required in some special cases (such as in the hidden prefix scenario where only the operator knows the hidden prefix), automation can reduce considerable operational overhead in general.¶
The new intra-domain SAV mechanism MUST specify the deployment scope (i.e., where this mechanism will be used) and provide incremental benefits when incrementally deployed within the specified deployment scope. That is, it MUST NOT be effective only when fully deployed. As current intra-domain SAV mechanisms already meet this requirement, the new SAV mechanism MUST meet this requirement as well. Furthermore, the new SAV mechanism MUST avoid improper blocks and identify no less spoofing traffic than the current ones in the same incremental deployment scenario.¶
The new intra-domain SAV mechanism MUST update SAV rules in time when prefix changes, route changes, or topology changes occur in an intra-domain network. To this end, two considerations must be taken into account when designing the new SAV mechanism. First, the mechanism MUST allow routers to exchange the updated SAV-specific information in a timely manner. Second, the mechanism MUST NOT require routers to signal too much information for the SAV function, because this will greatly increase the load on the control plane, even compromising the convergence of the current protocols.¶
Necessary security mechanisms SHOULD be considered in the new intra-domain SAV mechanism if it may face new security risks. Section 6 details the security scope and security considerations for the new intra-domain SAV mechanism.¶
The new intra-domain SAV mechanisms should not introduce additional security vulnerabilities or confusion to the existing intra-domain architectures or control or management plane protocols.¶
Similar to the security scope of intra-domain routing protocols, intra-domain SAV mechanisms should ensure integrity and authentication of protocol messages that deliver the required SAV-specific information, and consider avoiding unintentional misconfiguration. It is not necessary to provide protection against compromised or malicious intra-domain routers which poison existing control or management plane protocols. Compromised or malicious intra-domain routers may not only affect SAV, but also disrupt the whole intra-domain routing domain. Security mechanisms to prevent these attacks are beyond the capability of intra-domain SAV.¶
This document does not request any IANA allocations.¶
Many thanks to the valuable comments from: Jared Mauch, Barry Greene, Fang Gao, Kotikalapudi Sriram, Anthony Somerset, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, Libin Liu, John O'Brien, Roland Dobbins, Xiangqing Chang, Tony Przygienda, Yingzhen Qu, Changwang Lin, James Guichard, Linda Dunbar, Robert Sparks, Yu Fu, Stephen Farrel etc.¶