Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements

Introduction Source Address Validation (SAV) defends against source address spoofing. Network operators can enforce SAV at the following levels (see ):

IP source address validation in the access network
IP source address validation at intra-AS/ingress point
IP source address validation in the inter-AS Case (neighboring AS)

Some access networks have already deployed SAV mechanisms. These mechanisms typically are deployed on switches in the access network and prevent hosts from using the source address of another host on the Internet . Mechanisms include:

Source Address Validation Improvement (SAVI) Solution for DHCP
IP Source Guard (IPSG) based on DHCP snooping
Cable Source-Verify

However, access-network SAV mechanisms are not universally deployed . Therefore, intra-domain (i.e., intra-AS) SAV and inter-domain (i.e., inter-AS) SAV are required . This document provides a gap analysis of the current operational intra-domain SAV mechanisms and identifies requirements for new intra-domain SAV solutions. In this document, a domain refers to a routing domain under a single administrative control (e.g., an AS). Intra-domain SAV refers to SAV at a domain's external interfaces that do not carry external BGP (eBGP) sessions (i.e., non-BGP external interfaces). SAV at internal interfaces or BGP-facing external interfaces is considered out of scope. For a domain, as illustrated in , a non-BGP external interface may connect to a set of hosts, a non-BGP customer network, or a non-BGP Internet Service Provider (ISP) network. The goal of intra-domain SAV at such interfaces is to prevent traffic using unauthorized source addresses from entering the domain.

Deployment locations of intra-domain SAV

Terminology Non-BGP Customer Network: A stub network (i.e., a network that only originates traffic) connected to its provider network for Internet connectivity and does not participate in eBGP peering with its provider network. Non-BGP Internet Service Provider (ISP) Network: A network that forwards traffic from its customer network to the Internet and does not participate in eBGP peering with its customer network. 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. 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. Proper Block: The validation results that packets with spoofed source addresses are blocked by SAV rules. Proper Permit: The validation results that packets with legitimate source addresses are permitted by SAV rules. SAV-specific Information: The information specialized for SAV rule generation.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here. The requirements language is used in and applies to implementations of SAV conformant to the listed requirements.

Problem Statement of Current Operational Intra-domain SAV Mechanisms Although BCP 38 and BCP 84 specify several ingress filtering methods primarily intended for inter-domain SAV, some of these methods have also been applied to intra-domain SAV in operational practice. This section summarizes the problems of mechanisms currently used to implement intra-domain SAV. These mechanisms have significant limitations in terms of automated updates or accurate validation.

Access Control Lists (ACLs) can be used as SAV filters to check the source address of each packet against a set of permitted or prohibited prefixes. When applied on a router interface, each ACL entry (ACE) specifies both matching conditions (e.g., prefixes) and the corresponding action (e.g., permit or deny), and packets are processed accordingly. To ensure correct filtering behavior, changes in SAV state need to be reflected in corresponding ACL rules, which in turn need to be updated in accordance with changes in prefixes or topology; otherwise, packets may be improperly permitted or blocked. In ACL-based ingress filtering deployments, maintaining consistency between SAV state and ACL rules can introduce operational challenges, as this update process is often performed manually or requires significant operational intervention.
Strict uRPF provides an automated SAV filter by validating the source address of each packet against the router’s local Forwarding Information Base (FIB). A packet is accepted only if (i) the FIB contains a prefix covering the source address, and (ii) the FIB entry’s outgoing interface matches the packet’s incoming interface. Otherwise, the packet is discarded. It may block legitimate traffic in the asymmetric routing or hidden prefix scenarios (see and ). Strict uRPF may mistakenly consider a valid incoming interface as invalid, resulting in legitimate packets being blocked (i.e., an improper block problem).
Loose uRPF also relies on the local FIB for validation, but only checks for the presence of a covering prefix. A packet is accepted if the FIB contains a prefix that covers the source address, regardless of the incoming interface. Since its rules are overly permissive, any spoofed packet with a source address present in the FIB may be permitted by loose uRPF (i.e., an improper permit problem).
Enhanced Feasible Path uRPF (EFP-uRPF) is an advanced SAV mechanism specifically designed for inter-domain SAV. It enforces SAV on eBGP interfaces facing a customer AS by leveraging BGP data received from external ASes. EFP-uRPF is not analyzed in this document, as it is outside the scope of intra-domain SAV.

Gap Analysis This section analyzes the gaps and key challenges of the current operational intra-domain SAV mechanisms. ACL-based SAV can be deployed on interfaces facing a non-BGP customer network or a set of hosts, permitting only packets with authorized source addresses. Such mechanism can also be applied on interfaces facing a non-BGP ISP network to block packets with prohibited source addresses, including internal-use-only addresses, unallocated addresses, and addresses single-homed to the local domain (e.g., P1 and P2 in ). A key limitation of ACL-based SAV is the need to maintain consistency between SAV state and ACL rules. Operators need to update ACL rules to reflect changes in prefixes or topology, and delays or inconsistencies in this process may result in outdated rules that inadvertently block legitimate traffic or permit spoofed traffic. As noted in Section 2.4 of , loose uRPF sacrifices directionality, so its effectiveness in mitigating source address spoofing is very limited, and improper permit problems may occur. With strict uRPF, it may drop legitimate packets in scenarios such as asymmetric routing or hidden prefixes. The following subsections describe two specific gap scenarios that arise when using strict uRPF for intra-domain SAV.

Asymmetric Routing Scenario Asymmetric routing means a packet traverses from a source to a destination in one path and takes a different path when it returns to the source. Asymmetric routing can occur within an AS due to routing policy, traffic engineering, etc. For example, a non-BGP customer network connected to multiple routers of the AS may need to perform load balancing on incoming traffic, thereby resulting in asymmetric routing. illustrates an example of asymmetric routing. The non-BGP customer network owns prefix 2001:db8::/55 and connects to two routers of the AS, Router 1 and Router 2. Router 1, Router 2, and Router 3 exchange routing information via the intra-domain routing protocol. To achieve load balancing for inbound traffic, the non-BGP customer network expects traffic destined for 2001:db8:0::/56 to enter through Router 1, and traffic destined for 2001:db8:0:100::/56 to enter through Router 2. To this end, Router 1 advertises 2001:db8:0::/56 and Router 2 advertises 2001:db8:0:100::/56 through the intra-domain routing protocol. also shows the corresponding FIB entries of Router 1 and Router 2 for the two prefixes.

An example of asymmetric routing Although the non-BGP customer network does not expect to receive inbound traffic for 2001:db8:0:100::/56 via Router 1, it can send outbound traffic with source addresses in that prefix through Router 1. As a result, data packets between the non-BGP customer network and Router 1 may follow asymmetric paths. Arrows in the figure indicate the direction of traffic flow. If Router 1 enforces strict uRPF by checking the FIB entry for the prefix 2001:db8:0:100::/56, the corresponding SAV rule would only allow packets with a source address from 2001:db8:0:100::/56 that arrive via Router 3. Consequently, when the non-BGP customer network sends packets with a source address in 2001:db8:0:100::/56 to Router 1, strict uRPF would incorrectly drop these legitimate packets. Similarly, if Router 2 enforces strict uRPF, it would incorrectly block legitimate packets from the non-BGP customer network that use source addresses within the prefix 2001:db8:0::/56.

Hidden Prefix Scenario The intra-domain hidden prefix scenario refers to situations in which a host or non-BGP customer legitimately originates traffic using source addresses that are not visible to the intra-domain routing protocol within the domain.

A host (for example, a cloud server instance operated by a tenant) may originate traffic using a source address not allocated by the AS operator. This can occur in deployments such as Direct Server Return (DSR), where return traffic is sent directly from the server using a service IP address that is not part of the operator’s internal routing view.
A non-BGP customer network may originate traffic using source addresses that are not advertised to the domain operator. This can occur in scenarios such as Direct Server Return (DSR) deployments or when the customer network uses address space assigned by another provider (e.g., in multi-homing or hybrid connectivity scenarios), and such prefixes are not propagated within the operator’s intra-domain routing system.

For ACL-based SAV, enforcing correct filtering in these scenarios requires authoritative information that explicitly specifies which source addresses the host or non-BGP customer is authorized to use. In practice, such authoritative information is often missing. Existing uRPF-based mechanisms (strict uRPF or loose uRPF) also fail in hidden prefix scenarios. They will drop packets from hidden prefixes because the source addresses are absent from the router's FIB or are received from unexpected interfaces.

Requirements for New SAV Mechanisms The limitations described above primarily stem from the lack of SAV-specific authoritative information that can be consistently and automatically consumed by SAV mechanisms. Existing automated uRPF-based approaches derive SAV decisions from routing or forwarding state, which is intended to express reachability rather than authorization of source address usage. As a result, these mechanisms may not provide reliable validation in scenarios such as asymmetric routing or hidden prefixes. In contrast, ACL-based approaches can express source address authorization more precisely, but rely on ongoing operational intervention, which limits their applicability in dynamic operational environments. uRPF-based mechanisms rely on routing information to make SAV decisions, assuming that the routing information in the local FIB is correct. If the routing information is incorrect, SAV decisions may also be incorrect, potentially resulting in improper blocking or permitting. Ensuring the correctness of routing information is the responsibility of mechanisms or operational processes outside the scope of SAV. However, when SAV relies on routing information or other contextual information, such information is expected to be derived from trusted sources before being used. This section identifies five requirements to guide the design, development, and evaluation of new intra-domain SAV mechanisms, and to provide a common basis for improving upon existing approaches. These requirements are informational in nature. To avoid misinterpretation or misuse as a normative reference, it is noted that these informational requirements cannot be used to initiate standards-track protocol changes.

Accurate Validation Any new intra-domain SAV mechanism MUST improve the accuracy of source address validation compared to existing uRPF-based mechanisms. In particular, it MUST reduce the occurrence of improper blocks (i.e., blocking legitimate traffic), improper permits (i.e., allowing spoofed traffic), or both. Specifically, it MUST satisfy the following conditions:

result in fewer improper blocks than strict uRPF, particularly in scenarios involving asymmetric routes or hidden prefixes;
result in fewer improper permits than loose uRPF.

To achieve higher SAV accuracy, additional information beyond the local FIB (e.g., SAV-specific information) may be needed to make validation decisions. By integrating such information, routers may have the ability to account for asymmetric routes and hidden prefixes, resulting in more accurate SAV rules.

Automatic Updates Any new intra-domain SAV mechanism MUST be capable of automatically collecting and processing relevant information, and using it to derive and update SAV state and corresponding filtering rules on routers. Automation helps reduce operational complexity and maintenance overhead, while allowing some initial configuration to improve SAV accuracy. This ensures the mechanism is deployable in practical networks without introducing excessive management burden.

Incremental Deployment Support Any new intra-domain SAV mechanism MUST support incremental deployment and provide measurable benefits even when only a subset of external non-BGP interfaces deploy the mechanism.

Fast Convergence If any new intra-domain SAV mechanism requires disseminating SAV-specific information among intra-domain routers via a protocol, two considerations are essential. First, such mechanism MUST allow routers to learn updated SAV-specific information in a timely manner. Second, such mechanism MUST NOT transmit excessive SAV-specific information via a protocol, as this could significantly increase the burden on the routers’ control planes and potentially degrade the performance of existing protocols.

Authentication of Information Used for SAV Any new intra-domain SAV mechanism MUST use information that is authenticated or trusted, either through verification of its integrity and authenticity, or via an established trust relationship with the information source. If a SAV mechanism introduces new SAV-specific information, such information MUST be authenticated to ensure its integrity and authenticity before being used for SAV decision making.

Vulnerability Prevention Any new intra-domain SAV mechanism MUST NOT introduce additional security vulnerabilities to existing intra-domain architectures or protocols. Protection against compromised or malicious intra-domain routers is out of scope, as such routers can compromise not only SAV mechanisms but also the entire intra-domain routing domain.

Security Considerations This document discusses the limitations of existing intra-domain SAV practices and identifies problems and informational requirements for improved intra-domain SAV mechanisms. It does not specify new protocols or mechanisms and, as such, does not introduce any new security considerations.

IANA Considerations This document does not request any IANA allocations.

Acknowledgements Many thanks to the valuable comments from: Jared Mauch, Joel Halpern, Aijun Wang, Michael Richardson, Gert Doering, Libin Liu, Li Chen, Tony Przygienda, Yingzhen Qu, James Guichard, Linda Dunbar, Robert Sparks, Stephen Farrel, Ron Bonica, Xueyan Song, etc. We also thank the IETF Directorates and the IESG for their reviews and comments, which helped improve the clarity of this document.