| Internet-Draft | Intra-domain SAVNET Problem Statement | May 2025 |
| Li, et al. | Expires 14 November 2025 | [Page] |
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic 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 14 November 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. Network operators can implement SAV mechanisms at multiple levels: access-network SAV, intra-domain SAV, and inter-domain SAV (see [RFC5210]). Access-network SAV (e.g., SAVI [RFC7513], IP Source Guard (IPSG) based on DHCP snooping [IPSG], and Cable Source-Verify [cable-verify]) is typically deployed on switches inside the access network to prevent a host from using the source address of another host in the same network segment. When access-network SAV is not universally deployed, intra-domain SAV on routers of the Autonomous System (AS) can increase the defense in depth by blocking spoofing traffic as close to the source as possible.¶
This document focuses only on the analysis of intra-domain SAV (also known as intra-AS SAV). Unlike inter-domain SAV (also known as inter-AS 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 with local information (e.g., local configuration or Interior Gateway Protocol (IGP) data).¶
Specifically, as illustrated in Figure 1, intra-domain SAV for an AS achieves two goals: i) prevent a sub network from using a source address out of the sub network or prevent a directly-connected host from using a source address out of the network segment; and ii) prevent spoofed data packets coming from the rest of the Internet that use a source address of the local AS. A sub network is part of the AS. It consists of routers and hosts and may run a routing protocol among its routers. It only originates traffic and is connected to one or more routers of the AS for Internet connectivity.¶
Case i: A sub network or a directly-connected host
originates spoofed data packets using a source address
out of the sub network or the network segment
Goal i: If the AS deploys intra-domain SAV,
the spoofed data packets can be blocked
+----------------------------------------------------------------+
| AS Spoofed data packets using |
| a source address out of |
|+----------------------------+ the sub network or |
|| A sub network or | the network segment +--------+|
|| a directly-connected host |----------------------->| Router ||
|+----------------------------+ +--------+|
+----------------------------------------------------------------+
Case ii: The AS receives spoofed data packets using a source
address of the local AS from the rest of the Internet
Goal ii: If the AS deploys intra-domain SAV,
the spoofed data packets can be blocked
Spoofed data packets
using a source address
+----+ of the local AS +--------------------------+
| AS |<---------------------| The rest of the Internet |
+----+ +--------------------------+
In the following, this document provides a gap analysis of the current operational intra-domain SAV mechanisms, concludes key problems to solve, and proposes basic requirements for future ones.¶
Sub Network: A sub network is part of the AS. It consists of routers and hosts and may run the routing protocol among its routers. It only originates traffic and is connected to one or more routers of the AS for Internet connectivity.¶
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.¶
SAV-specific Information: The information specialized for SAV rule generation.¶
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.¶
Although BCP38 [RFC2827] and BCP84 [RFC3704] provides multiple ingress filtering methods which are typically used for inter-domain SAV, some of them have also been used for intra-domain SAV in practice. This section introduces the current operational mechanisms used to implement intra-domain SAV.¶
Access Control List (ACL) [RFC2827] is a SAV filter that checks the source address of every data packet against a list of acceptable or unacceptable prefixes. By performing the ACL rule at a router interface, every data packet received at this interface that does not match the ACL rule will be blocked. It can be used at router interfaces facing a sub network or a set of hosts, only allowing data packets using an acceptable source address. It is also usually used on router interfaces facing the rest of the Internet, blocking data packets using an unacceptable source address, such as internal source addresses owned by the local AS [nist-rec]. The ACL rule is typically configured and updated manually, so it is critical to update ACL rules in time when the set of prefixes changes.¶
Strict uRPF [RFC3704] implements a SAV filter in an automatic way by checking the source address of every data packet against the router's local Forwarding Information Base (FIB). The router deploying strict uRPF accepts 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. Strict uRPF is often used to block spoofed data packets originated from a sub network or a directly-connected host.¶
Loose uRPF [RFC3704] also uses the local FIB to implement SAV but checks only for the existence of the prefix. Loose uRPF accepts a data packet 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. Routers can use loose uRPF to block spoofed data packets using a non-global or non-routed source address [nist-rec].¶
EFP-uRPF [RFC8704] is another advanced SAV mechanism but it is specifically designed for inter-domain SAV. It implements a SAV filter on router interfaces facing a customer AS by using BGP data provided by other ASes. This document does not analyze EFP-uRPF because it is out of the scope.¶
This section elaborates the gap scenarios and key problems of the current operational intra-domain SAV mechanisms.¶
Towards Goal i described in Section 1 and shown in Figure 1, the AS operator can use ACL rules or strict uRPF on appropriate routers to implement intra-domain SAV for traffic originated from a sub network or a directly-connected host.¶
For example, the AS operator can configure an ACL rule on router interfaces facing a sub network or a directly-connected host, containing a set of prefixes which can be used as the source address. By using this ACL rule, the router will block any data packet using a source address out of the set of prefixes. However, the key problem of ACL-based SAV is the high operational overhead. Since the ACL rule is typically maintained manually, the AS operator must update the ACL rule according to prefix changes or topology changes timely. If the AS operator forgets to update the ACL rule when the set of prefixes changes, the outdated ACL rule may improperly block legitimate data packets.¶
Strict uRPF can generate and update SAV rules in an automatic way but it will improperly block legitimate data packets in the scenario of asymmetric routing or hidden prefix. In the following, this section introduces two gap scenarios when using strict uRPF to implement intra-domain SAV.¶
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 sub network connected to multiple routers of the AS may need to perform load balancing on incoming traffic, thereby resulting in asymmetric routing.¶
Figure 2 shows an example of asymmetric routing. The sub network owns prefix 2001:db8::/55 [RFC6890] and is connected to two routers of the AS, i.e., Router 1 and Router 2. Router 1, Router 2, and Router 3 exchange routing information through the intra-domain routing protocol. For load balancing of traffic flowing to the sub network, the sub network expects the incoming traffic destined for prefix 2001:db8:0::/56 to come from Router 1 and the incoming traffic destined for prefix 2001:db8:0:100::/56 to come from Router 2. To this end, it requires that Router 1 advertises the route information of prefix 2001:db8:0::/56 and Router 2 advertises the routing information of prefix 2001:db8:0:100::/56 through the intra-domain routing protocol. Figure 2 shows the FIB entries of Router 1 and Router 2 associated with the two prefixes.¶
+----------------------------------------------------------+
| AS |
| +----------+ |
| | 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 |
| +----------------+ |
| | Sub | |
| | Network | |
| |(2001:db8::/55) | |
| +----------------+ |
| |
+----------------------------------------------------------+
FIB of Router 1 FIB of Router 2
Dest Next_hop Dest Next_hop
2001:db8:0::/56 Sub 2001:db8:0:100::/56 Sub
Nestwork Network
2001:db8:0:100::/56 Router 3 2001:db8:0::/56 Router 3
The legitimate traffic originated from sub network with
source addresses in 2001:db8:0:100::/56 will be improperly blocked
by strict uRPF on Router 1.
While the sub network does not expect traffic destined for prefix 2001:db8:0:100::/56 to come from Router 1, it can send traffic with source addresses of prefix 2001:db8:0:100::/56 to Router 1. As a result, there is asymmetric routing of data packets between the sub network and Router 1. Arrows in the figure indicate the flowing direction of traffic. If Router 1 adopts strict uRPF, by checking the FIB entry that matches prefix 2001:db8:0:100::/56, the SAV rule is that Router 1 only accepts data packets with a source address of 2001:db8:0:100::/56 from Router 3. Therefore, when the sub network sends data packets with a source address of 2001:db8:0:100::/56 to Router 1, strict uRPF on Router 1 will improperly block these legitimate data packets. Similarly, if Router 2 adopts strict uRPF, it will improperly block legitimate data packets from the sub network that use a source address of prefix 2001:db8:0::/56.¶
Towards Goal ii described in Section 1 and shown in Figure 1, intra-domain SAV is typically deployed on router interfaces facing the rest of the Internet to block data packets using an internal source address (see Figure 4). ACL-based SAV is often used for this purpose. The AS operator can configure an ACL rule which contains a set of unacceptable prefixes (e.g., internal prefixes) to block any data packet using a source address of these prefixes. However, the operational overhead of maintaining ACL rules will be extremely high, especially when there are multiple router interfaces that need to configure the ACL rule as shown in Figure 4.¶
+---------------------------------------------------+
| The rest of the Internet |
+---------------------------------------------------+
| Data packets using an |
| internal source address |
| (e.g., P1 or P2) |
+-------------|---------------------------|---------+
| AS \/ \/ |
| +---#------+ +----#-----+ |
| | Router 3 +---------------+ Router 4 | |
| +----------+ +----------+ |
| / \ | |
| / \ | |
| / \ | |
| +----------+ +----------+ +----------+ |
| | Router 1 | | Router 2 +------+ Router 5 | |
| +----------+ +----------+ +----------+ |
| \ / | |
| \ / | |
| \ / | |
| +---------------+ +-------+-------+ |
| | Sub | | Hosts | |
| | Network | | | |
| | (P1) | | (P2) | |
| +---------------+ +---------------+ |
| |
+---------------------------------------------------+
In addition, loose uRPF can be used in this case to block data packets from the rest of the Internet using a non-global or non-routed source address. But it will improperly permit spoofed data packets using an internal source address because internal prefixes/addresses exist in the router's local FIB.¶
As analyzed above, the current operational intra-domain SAV mechanisms have significant limitations in terms of automatic update or accurate validation.¶
ACL-based SAV entirely relies on manual maintenance and thus requires high operational overhead in dynamic networks. To guarantee accuracy of ACL-based SAV, AS operators have to manually update the ACL rule 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. As analyzed in Section 3.1, it may mistakenly consider a valid incoming interface as invalid, resulting in legitimate data packets being blocked (i.e., improper block problem).¶
Loose uRPF is also an automated SAV mechanism but its SAV rules are overly loose. As analyzed in Section 3.2, any spoofed data packet using a source address covered by the FIB will be accepted by loose uRPF (i.e., improper permit problem).¶
In summary, the AS operator has a comprehensive perspective, so it can configure the correct ACL rules. However, manual maintenance can lead to high operational overhead and improper blocks may occur due to the negligence of the AS operator. uRPF cannot guarantee the accuracy of SAV because it solely uses the router’s local FIB information to determine SAV rules, which may not match the incoming interfaces of legitimate data packets from the source. As a result, strict uRPF will improperly block legitimate data packets in the case of asymmetric routing and hidden prefix, while loose uRPF has limited effect on preventing source address spoofing because it only blocks non-global or non-routed addresses.¶
To address the problems of current intra-domain SAV mechanisms, this section lists five basic requirements for technical improvements 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 block those spoofing traffic from sub networks, hosts, and the rest of the Internet. Meanwhile, it MUST avoid blocking legitimate data packets, especially when there are prefix changes, asymmetric routes, or hidden prefixes. To overcome the improper block problems, routers may need to use more information (e.g., SAV-specific information) besides the local FIB information to determine SAV decisions. By integrating SAV-specific information, routers may learn asymmetric routes or hidden prefixes, resulting in more accurate SAV rules.¶
The new intra-domain SAV mechanism MUST be able to automatically generate and update SAV rules on routers, rather than relying entirely on manual updates like ACL-based SAV. Even if some necessary initial configurations may be needed to improve the accuracy of SAV, automation helps reduce subsequent maintenance overhead of the AS operator.¶
The new intra-domain SAV mechanism MUST specify the deployment scope (i.e., which routers the mechanism is used on) and MUST provide incremental benefits when incrementally deployed within the specified deployment scope. That is, it MUST NOT be effective only when fully deployed within the deployment scope. In the incremental deployment scenario, it MUST be able to fulfill or partially fulfill the goals described in Section 1 and MUST avoid improper blocks.¶
The new intra-domain SAV mechanism MUST be able to update SAV rules in time when prefix changes, route changes, or topology changes occur in an AS. Two considerations must be taken into account if SAV-specific information is communicated through a protocol. First, the mechanism MUST allow routers to learn the updated SAV-specific information in a timely manner. Second, the mechanism MUST NOT communicate too much SAV-specific information for the SAV function, because this may greatly increase the burden on the control plane of routers and even compromise the performance of the current protocols.¶
Similar to the security scope of intra-domain routing protocols, intra-domain SAV mechanisms can 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.¶