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

Status of This Memo

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 20 September 2026.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

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

• Within the access network¶

• Within the domain (i.e., the autonomous system)¶

• Between domains (i.e., autonomous systems)¶

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

• Source Address Validation Improvement (SAVI) Solution for DHCP [RFC7513]¶

• IP Source Guard (IPSG) based on DHCP snooping [IPSG]¶

• Cable Source-Verify [cable-verify]¶

However, access-network SAV mechanisms are not universally deployed. Therefore, intra-domain (i.e., intra-AS) SAV or/and inter-domain (i.e., inter-AS) SAV are required.¶

This document provides a gap analysis of the current operational intra-domain SAV mechanisms, identifies key problems to solve, and proposes basic requirements for any new intra-domain SAV solutions.¶

In this document, intra-domain SAV refers to SAV at external interfaces that do not carry external BGP (eBGP) sessions (i.e., external non-BGP interfaces). SAV at internal interfaces or eBGP interfaces is considered out of scope. Within a domain, as illustrated in Figure 1, an external non-BGP 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.¶

      +-----------------+         +---------------+
      |   Non-BGP ISP   |         | eBGP Neighbor |
      +-----------------+         +---------------+
              |                           |
              |                           |
              |                           |
+-------------|---------------------------|---------+
|Domain       \/                          |         |
|         +---#------+               +----------+   |
|         | Router 3 +---------------+ Router 4 |   |
|         +----------+               +----------+   |
|          /        \                     |         |
|         /          \                    |         |
|        /            \                   |         |
| +----------+     +----------+      +----------+   |
| | Router 1 |     | Router 2 +------+ Router 5 |   |
| +------*---+     +--*-------+      +----X-----+   |
|        /\           /\                  /\        |
|         \           /                   |         |
+----------\---------/--------------------|---------+
       +----------------+         +---------------+
       |Non-BGP Customer|         |   A Set of    |
       |   Network      |         |     Hosts     |
       |     (P1)       |         |     (P2)      |
       +----------------+         +---------------+

  This document focuses on SAV at external non-BGP
  interfaces including Interfaces  'X', '*', and '#'.

2. Current Operational Intra-domain SAV Mechanisms

Although BCP 38 [RFC2827] and BCP 84 [RFC3704] 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 describes the mechanisms currently used to implement intra-domain SAV.¶

• Access Control Lists (ACLs) can be used as SAV filters [RFC2827] to check the source address of each packet against a set of permitted or prohibited prefixes. When applied on a router interface, packets that do not match the ACL entries are blocked. Since ACLs are configured and updated manually, timely updates are essential whenever the set of permitted or prohibited prefixes changes.¶

• Strict uRPF [RFC3704] 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.¶

• Loose uRPF [RFC3704] 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.¶

• Enhanced Feasible Path uRPF (EFP-uRPF) [RFC8704] 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.¶

3. 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 Figure 1). The main drawback of ACL-based SAV is that it requires manual maintenance. Operators must update them promptly to reflect changes in prefixes or topology. Failure to do so may result in outdated ACLs that inadvertently block legitimate traffic.¶

As noted in Section 2.4 of [RFC3704], 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.¶

 +----------------------------------------------------------+
 |Domain                                                    |
 |                      +----------+                        |
 |                      | Router 3 |                        |
 |                      +----------+                        |
 |                       /       \                          |
 |                      /         \                         |
 |                     /           \                        |
 |            +----------+       +----------+               |
 |            | Router 1 |       | Router 2 |               |
 |            +-----*----+       +----------+               |
 |                  /\               /                      |
 |                   \              /                       |
 +--------------------\------------/------------------------+
  Traffic with         \          / Traffic with
  source IP addresses   \        /  destination IP addresses
  of 2001:db8:0:100::/56 \      \/  of 2001:db8:0:100::/56
                    +----------------+
                    |Non-BGP Customer|
                    |    Network     |
                    |(2001:db8::/55) |
                    +----------------+

 FIB of Router 1                FIB of Router 2
 Dest                Next_hop   Dest                Next_hop
 2001:db8:0::/56     Non-BGP    2001:db8:0:100::/56 Non-BGP
                     Customer                       Customer
                     Nestwork                       Network
 2001:db8:0:100::/56 Router 3   2001:db8:0::/56     Router 3

 The legitimate traffic originated from non-BGP customer network
 with source addresses in 2001:db8:0:100::/56 will be improperly
 blocked by strict uRPF on Router 1.

4. Problem Statement

As discussed above, current operational intra-domain SAV mechanisms have significant limitations with respect to automatic updates and accurate validation:¶

• High operational overhead of ACL-based SAV. ACL-based SAV relies entirely on manual maintenance, resulting in high operational overhead in dynamic networks. To ensure the accuracy of ACL-based SAV, AS operators must manually update ACL rules whenever prefixes or topology change; otherwise, packets may be improperly blocked or permitted.¶

• Improper block prblem of strict uRPF. Strict uRPF can automatically update SAV rules based on the local FIB information, but it may block legitimate traffic in the asymmetric routing or hidden prefix scenarios. Strict uRPF may mistakenly consider a valid incoming interface as invalid, resulting in legitimate packets being blocked (i.e., an improper block problem).¶

• Improper permit problem of loose uRPF. Loose uRPF also automatically updates SAV rules based on the local FIB information, but 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).¶

The fundamental reason these limitations have persisted is the absence of SAV-specific, authoritative information that can be consumed automatically. Current automated uRPF-based mechanisms derive their SAV rules solely from routing or forwarding information. However, routing information is designed to express reachability rather than authorization to use a source address. As a result, uRPF-based mechanisms cannot reliably validate source addresses in scenarios such as asymmetric routing or hidden prefixes. While ACL-based SAV can accurately encode source address authorization, it relies on manual configuration and ongoing operator intervention. Such manual maintenance does not scale in dynamic networks. Consequently, addressing these gaps requires the introduction of SAV-specific, authoritative information and the design of automated mechanisms that can consume this information directly, rather than relying only on routing or forwarding state.¶

Another consideration is that 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, if SAV relies on routing information or other contextual information, it is highly recommended that such information be validated before being used for SAV.¶

5. Requirements for New SAV Mechanisms

This section outlines five general requirements for technical improvements that should be considered when designing future intra-domain SAV architectures and solutions. These informational requirements can not be used to initiate standards-track protocol changes.¶

6. 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.¶

7. IANA Considerations

This document does not request any IANA allocations.¶

8. 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.¶

9. References

Authors' Addresses