| Internet-Draft | Inter-domain SAVNET Problem Statement | March 2026 |
| Li, et al. | Expires 19 September 2026 | [Page] |
This document provides a gap analysis of existing inter-domain source address validation mechanisms, describes the problem space, 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 19 September 2026.¶
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.¶
Source Address Validation (SAV) is a fundamental mechanism for detecting and mitigating source address spoofing attacks [RFC2827] [RFC5210] [RFC3704] [RFC8704]. This document provides a gap analysis of existing inter-domain SAV mechanisms, describes the problem space, and defines the requirements for technical improvements. The corresponding work related to intra-domain SAV is documented in [I-D.ietf-savnet-intra-domain-problem-statement].¶
In this document, inter-domain SAV refers to SAV on AS-to-AS interfaces that carry external BGP (eBGP) sessions. The eBGP sessions include Customer-to-Provider (C2P), Provider-to-Customer (P2C), lateral peering (P2P), and Route Server (RS) to RS-client connections. The terms customer, provider (transit provider), and lateral peer (non-transit peer; peer (for simplicity)) used in this document are consistent with those defined in [RFC7908] [RFC9234]. Further, [RFC9234] mentions RS and RS-client. An RS-to-RS-client interface is akin to the customer interface. For the purposes of SAV, an RS-client-to-RS interface may be treated (1) like a provider interface for simplicity, or (2) like a union of lateral peers considering all the ASes the RS-client chose to peer with at the IXP RS.¶
Access Control List (ACL) and unicast Reverse Path Forwarding (uRPF) based techniques are currently utilized to some extent for inter-domain SAV. In this document, the inter-domain SAV methods from only the existing IETF RFCs (BCP 38 [RFC2827] and BCP 84 [RFC3704] [RFC8704]) are considered for the gap analysis; IETF work-in-progress documents are not considered. Other documents, such as [SAC-004], discuss the underlying anti-spoofing problem space from an operational and security perspective, but are not used as the basis of the method-by-method gap analysis. This document analyzes the available methods and attempts to answer: (1) what are the technical gaps (Section 4), (2) what are the outstanding problems (problem statement) (Section 5), and (3) what are the practical requirements for the solutions to these problems (Section 6).¶
The following summarizes the fundamental problems with existing SAV mechanisms, as analyzed in Section 4 and Section 5:¶
Improper block: Existing uRPF-based mechanisms suffer from improper block (false positives) in two inter-domain scenarios: limited propagation of a prefix and hidden prefix.¶
Improper permit: With some existing uRPF-based SAV mechanisms, improper permit (false negatives) can happen on any type of interface (customer, lateral peer, or provider). Specifically, if the method relaxes the directionality constraint [RFC3704] [RFC8704] to try to achieve zero improper blocking, the possibility of improper permit increases. (Note: It is recognized that unless there is full adoption of SAV in the customer cone (CC) of the interface in consideration, improper permit is not fully preventable in scenarios where source address spoofing occurs from within the CC, i.e., a prefix at one Autonomous System (AS) in the CC is spoofed from another AS in the same CC.)¶
High operational overhead: ACL-based ingress SAV filtering introduces significant operational overhead, as it needs to update ACL rules manually to adapt to prefix or routing changes in a timely manner. The high operational overhead issue does not pertain to existing uRPF-based mechanisms.¶
To address these problems, this document specifies (Section 6) the following key technical requirements for any new solution:¶
Improved SAV accuracy over existing mechanisms: Any new inter-domain SAV mechanism MUST NOT be worse than existing inter-domain SAV mechanisms in terms of improper block and improper permit. It SHOULD avoid improper blocking and improve the directionality of filtering (i.e., rejecting spoofed traffic).¶
Reduced operational overhead: Any new inter-domain SAV mechanism SHOULD be able to automatically adapt to network dynamics and asymmetric routing scenarios. Any such solution MUST have less operational overhead than ACL-based ingress SAV filtering.¶
Benefit in incremental/partial deployment: Any new solution MUST NOT assume pervasive adoption of the SAV method, the SAV-related information (Section 2), or the SAV-specific information (Section 2). It SHOULD benefit early adopters by providing effective protection from spoofing of source addresses even in partial deployment.¶
Automatic updates to the SAV list and efficient convergence: Any new inter-domain SAV mechanism SHOULD be responsive to changes in the SAV-related information or the SAV-specific information. It SHOULD automatically update the SAV list while achieving efficient re-convergence of the same.¶
Providing necessary security guarantee: If any proposed new SAV method requires exchanging SAV-specific information between ASes, security mechanisms must exist to prevent malicious injection or alteration of the SAV-specific information.¶
In addition, any new inter-domain SAV mechanisms should avoid packet modification in the data plane. Note that this document focuses on inter-domain SAV mechanisms that validate and filter packets without modifying data plane packets. This scope limitation is intentional, since allowing packet modification would introduce additional design, forwarding, interoperability, and deployment considerations beyond the problem space studied in this document. Therefore, packet-modifying approaches are outside the scope of this document.¶
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.¶
The table of prefixes that indicates the validity of a specific source IP address or source IP prefix per interface. Sometimes the terms 'RPF (Reverse Path Forwarding) list' or 'SAV rules' are used interchangeably with 'SAV list'.¶
The validation results in packets with legitimate source addresses being blocked improperly due to an inaccurate SAV list.¶
The validation results in packets with spoofed source addresses being permitted improperly due to an inaccurate SAV list.¶
The Customer Cone of a given AS, denoted as AS-A, includes: (1) AS-A itself, (2) AS-A's direct customers (ASes), (3) The customers of AS-A's direct customers (indirect customers), (4) And so on, recursively, following all chains of provider-to-customer (P2C) links down the hierarchy.¶
IP prefixes permitted by their owners to be originated by, or used as source addresses for data traffic originated from, one or more ASes within the CC.¶
Routing information (e.g., RIB and FIB) and objects published in the Resource Public Key Infrastructure (RPKI) that were originally proposed for non-SAV purposes but may also be used for SAV. The RPKI objects include existing RPKI object types (e.g., ROAs and ASPAs) as well as any new types that may be proposed.¶
Information dedicated to SAV, which may be defined and exchanged between ASes using a potentially new inter-AS communication protocol or an extension of an existing protocol. The information may also take the form of new RPKI object type(s) or management information from operators.¶
Inter-domain SAV is typically performed at the AS level (on a per neighbor-AS-interface basis) and can be deployed at AS border routers (ASBRs) to prevent source address spoofing. There are various mechanisms available to implement inter-domain SAV for anti-spoofing ingress filtering [nist] [manrs] [isoc], which are reviewed in this section.¶
ACL-based ingress filtering [RFC3704]: ACL-based ingress SAV filtering is a technique that relies on ACL rules to filter packets based on their source addresses. However, ACL-based ingress SAV filtering introduces significant operational overhead, as ACL rules need to be updated in a timely manner to reflect prefix or routing changes in the inter-domain routing system. One may think of using ACL as a disallow list on a provider interface to block source prefixes that are clearly invalid in the inter-domain routing context, such as IANA special purpose or unallocated IPv4/IPv6 prefixes, etc. But it is impractical to store and maintain a very large and dynamically varying set of unallocated IPv6 prefixes. Also, for the customer interfaces, the ACL method is impractical while other techniques (as described below) are more effective. ACL-based ingress SAV filtering has applicability for broadband cable or digital subscriber access loop (DSL) access networks where the service provider has clear knowledge of IP address prefixes it has allocated to manage those services. Here ACL can be used in an allow-list form.¶
uRPF-based mechanisms: A class of SAV mechanisms are based on Unicast Reverse Path Forwarding (uRPF) [RFC3704] [RFC8704]. The core idea of uRPF for SAV is to exploit the symmetry of inter-domain routing: in many cases, the best next hop for a destination is also the best previous hop for the source. In other words, if a packet arrives from a certain interface, the source address of that packet should be reachable via the same interface, according to the FIB. However, symmetry in routing does not always hold in practice, and to address cases where it does not hold, many enhancements and modes of uRPF have evolved. Different modes of uRPF have different levels of strictness and flexibility, and network operators can choose from them to suit particular network scenarios. We briefly describe these modes as follows:¶
Strict uRPF [RFC3704]: Strict uRPF is the most stringent mode. It permits a packet only if it has a source address that is covered by a prefix in the FIB, and the next hop for that prefix is the same interface that the packet arrived on. This mode can be deployed at customer interfaces in some scenarios, e.g., a directly connected single-homed stub customer AS [nist].¶
Loose uRPF [RFC3704]: Loose uRPF verifies that the source address of a packet is routable on the internet by matching it with one or more prefixes in the FIB, regardless of the interface on which the packet arrives. If the source address is not routable, Loose uRPF discards the packet. Loose uRPF is typically deployed at the provider interfaces of an AS to block packets with source addresses from prefixes that are not routed on the global internet (e.g., IANA-allocated private-use addresses, unallocated IPv4/IPv6 addresses, multicast addresses, etc.).¶
Feasible Path uRPF (FP-uRPF) [RFC3704]: Unlike Strict uRPF, which requires the packet to arrive on the exact best return path, FP-uRPF allows a packet to pass as long as the router could reach that source address through the interface it arrived on (based on the feasible routes in the Adj-RIBs-In [RFC4271]), even if the route isn't the primary route (per best path selection). This makes it more effective in multi-homed environments where asymmetric routing is common, as it prevents legitimate traffic from being dropped simply because it didn't take the "best" path back to the sender.¶
Enhanced Feasible Path uRPF with Algorithm A (EFP-uRPF Alg-A) [RFC8704]: EFP-uRPF Alg-A expands the list of valid source addresses for a specific interface by including all prefixes associated with any Origin AS that is reachable through that interface. Instead of only accepting prefixes directly advertised on a link, the router identifies all the origin ASes present in the BGP updates received on that interface and then permits any prefix from those same ASes that it sees elsewhere in its Adj-RIBs-In (associated with all neighbors — customers, providers, peers). This "Origin AS-based" approach provides significantly more flexibility than strict or traditional FP-uRPF, as it accounts for cases where an AS in the CC may send traffic for one of its prefixes over a link where it only advertised a different prefix (multi-homing and asymmetric routing scenarios).¶
Enhanced Feasible Path uRPF with Algorithm B (EFP-uRPF Alg-B) [RFC8704]: EFP-uRPF Alg-B provides even greater flexibility (compared to EFP-uRPF Alg-A) by aggregating all customer interfaces into a single "customer group" for validation purposes. The router first identifies all unique prefixes and origin ASes associated with all directly connected customer interfaces using only the Adj-RIBs-In associated with them. It then constructs a comprehensive RPF list that includes every prefix originated by those ASes, regardless of whether those prefixes were learned via customer, peer, or transit provider links. This list is applied uniformly across all customer-facing interfaces, attempting to ensure that legitimate traffic from a multihomed AS in the CC is never dropped, even if the traffic arrives on a different customer-facing port than the one where the specific prefix was advertised. In comparison to EFP-uRPF Alg-A, this method (Alg-B) reduces the possibility of improper block but at the expense of increased possibility of improper permit, i.e., reduced directionality.¶
Virtual Routing and Forwarding (VRF) uRPF [RFC4364] [urpf] [manrs]: VRF uRPF uses a separate VRF table for each external BGP peer and is only a way of implementation for a SAV list.¶
Inter-domain SAV is essential for preventing source address spoofing traffic at all AS interfaces — customers, providers, and lateral peers. An ideal inter-domain SAV mechanism must block all spoofing traffic while permitting legitimate traffic in all scenarios of interest. However, in some cases, existing SAV mechanisms may unintentionally block legitimate traffic or permit spoofing traffic. This section aims to conduct a gap analysis of existing SAV mechanisms for different types of interfaces under various scenarios to identify their technical limitations.¶
To prevent source address spoofing on customer interfaces, operators can enable ACL-based ingress filtering, or uRPF-based mechanisms such as Strict uRPF, FP-uRPF, or EFP-uRPF. However, the ACL method typically has high operational overhead. The uRPF-based mechanisms may cause improper block in two inter-domain scenarios: Limited Propagation of a Prefix and Hidden Prefix. They may also cause improper permit in the scenarios of source address Spoofing within a CC. One example for Limited Propagation of a Prefix scenario is when an AS attaches NO_EXPORT BGP Community to some prefixes (routes) forwarded to some upstream providers (in multi-homing scenarios) (see Section 4.1.1). Sometimes this scenario occurs by selectively propagating different sets of prefixes to different upstream providers. The Hidden Prefix scenario is typically associated with the Direct Server Return (DSR) scenario; anycast prefix in a Content Delivery Network (CDN) application is not announced by the AS where the DSR (edge server) is located (see Section 4.1.2). Source address Spoofing within a CC scenario arises when a prefix at one AS in the CC is spoofed from another AS in the same CC Section 4.1.3. It is recognized that unless there is full adoption of SAV in the CC of the interface in consideration, improper permit is not fully preventable in the Source address Spoofing within a CC scenario.¶
Figure 1 provides an overview of the gaps associated with the ACL method, Strict uRPF, FP-uRPF, and EFP-uRPF for SAV at customer interfaces in the Limited Propagation of a Prefix, Hidden Prefix, and Source address Spoofing within a CC scenarios mentioned above. Illustrations and analyses of these gaps are provided in Section 4.1.1, Section 4.1.2, and Section 4.1.3, respectively.¶
+--------------------+------------+-----------+-------+--------+ |Traffic & Scenarios | ACL |Strict uRPF|FP-uRPF|EFP-uRPF| +----------+---------+------------+-----------+-------+--------+ |Legitimate| LPP | | | |Traffic +---------+ | Improper Block | | | HP | High | possible | +----------+---------+Operational-+-------------------+--------+ | | | Overhead | |Improper| |Spoofed | no SCC | | |Permit | |Traffic | | | Functions as |only for| | | | | Expected |EFP-uRPF| | | | | |Alg-B | |+---------+---------+ +-------------------+--------| |Spoofed | SCC | | | |Traffic | | | Improper Permit | | | | | (in partial deployment) | +----------+---------+------------+----------------------------+ LPP = Limited Propagation of a Prefix HP = Hidden Prefix SCC = Spoofing within a CC 'Functions as Expected' connotes the absence of improper permit. It also connotes low operational overhead.
In inter-domain networks, some prefixes may not propagate from a customer to all its providers and/or may not propagate transitively from the providers to all their providers due to various factors, such as the use of NO_EXPORT or NO_ADVERTISE Communities, or some other selective-export policies. In these cases, it is possible that a prefix (route) announcement in the CC associated with a customer interface has limited propagation in the CC and is not received on that interface. Then the prefix is invisible in BGP at that interface but the traffic with source address in that prefix may still be received on that interface. This can give rise to improper block when performing SAV with existing mechanisms. These mechanisms include EFP-uRPF Alg-A, which is the focus on in the following analysis, while it also applies to Strict uRPF and FP-uRPF. All these mechanisms suffer from the same problem of improper block in this scenario.¶
+----------------+
| AS 3(P3) |
+-+/\------+/\+--+
/ \
/ \
/ \
/ (C2P) \
+------------------+ \
| AS 4(P4) | \
++/\+--+/\+----+/\++ \
/ | \ \
P2[AS 2] / | \ \
/ | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
| AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
\ | \ \
P1[AS 1] \ | \ \
NO_EXPORT \ | \ \
\(C2P) |(C2P) (C2P)\ (C2P)\
+----------------+ +----------------+
| AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
In the scenario of Figure 2, AS 1 is a customer of AS 2; AS 1 and AS 2 are customers of AS 4; AS 4 is a customer of AS 3; and AS 5 is a customer of both AS 3 and AS 4. AS 1 advertises prefixes P1 to AS 2 with the NO_EXPORT community attribute attached, preventing AS 2 from further propagating the route for prefix P1 to AS 4. Consequently, AS 4 only learns the route for prefix P1 from AS 1 in this scenario. Suppose AS 1 and AS 4 have deployed inter-domain SAV while other ASes have not, and AS 4 has deployed EFP-uRPF at its customer interfaces.¶
If AS 4 deploys EFP-uRPF Alg-A at customer interfaces, it will require packets with source addresses in P1 or P6 to only arrive on the interface with AS 1. When AS 1 sends legitimate packets with source addresses in P1 or P6 to AS 4 via AS 2, AS 4 improperly blocks these packets. The same improper block problem occurs with the use of Strict uRPF or FP-uRPF. EFP-uRPF with Alg-B can avoid the improper block in this specific scenario, but even this SAV method would have the improper block if the TE at AS 1 is such that none of the customer interfaces at AS 4 receives a route for P1 (or P6).¶
CDNs use the concepts of anycast [RFC4786][RFC7094] and DSR to improve the quality of service by placing edge servers with content closer to users. An anycast IP address is assigned to devices in different locations, and incoming requests are routed to the closest edge server (DSR) location. Usually, only locations with rich connectivity announce the anycast IP address through BGP. The CDN server receives requests from users and creates tunnels to the edge locations, from where content is sent directly to users. DSR requires servers in the edge locations to use the anycast IP address as the source address in response packets. However, the ASes serving the edge servers do not announce the anycast prefixes through BGP, so the anycast prefix is hidden (invisible in BGP) on the customer interface side at intermediate ASes which — with existing inter-domain SAV mechanisms — would improperly block the response packets.¶
Figure 3 illustrates a DSR scenario where the anycast IP prefix P7 is advertised by AS 3 through BGP. In this example, AS 3 is the provider of AS 4 and AS 5; AS 4 is the provider of AS 1, AS 2, and AS 5; and AS 2 is the provider of AS 1. AS 2 and AS 4 have deployed inter-domain SAV. When a user at AS 2 sends a request to the anycast destination IP, the forwarding path is AS 2->AS 4->AS 3. The anycast server in AS 3 receives the request and tunnels it to the edge servers in AS 1. Finally, the edge server sends the content packets to the user with source addresses in prefix P3. Let us say, the forwarding path for the content packets is AS 1->AS 2. Since AS 2 does not receive routing information for prefix P3 from AS 1, EFP-uRPF Alg-A or EFP-uRPF Alg-B (or any other existing uRPF-based mechanism) at the customer interface of AS 2 facing AS 1 will improperly block the response packets from AS 1.¶
+----------------+
Anycast Server+-+ AS 3(P3, P7) |
+-+/\----+/\+----+
/ \
P3[AS 3] / \ P3[AS 3]
P7[AS 3] / \ P7[AS 3]
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
/ | \ \
P3[AS 4, AS 3] / | \ \
P7[AS 4, AS 3] / | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
User+-+ AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
\ | \ \
P6[AS 1] \ | \ \
P1[AS 1] \ | \ \
\(C2P) |(C2P) (C2P)\ (C2P)\
+---------------+ +----------------+
Edge Server+-+ AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P7 is the anycast prefix and is advertised only by AS 3 via BGP.
Note that, unlike the other AS network figures in this document,
this figure illustrates that AS 3 advertises prefixes P3 and P7
to AS 2 through AS 4, and does not depict the propagation of
prefixes P1 and P6 beyond AS 2.
Further, there are cases of specific prefixes that may be exclusively used as source addresses (legitimately) without being advertised via BGP by any AS. While different from DSR scenarios, these cases similarly result in existing inter-domain SAV mechanisms improperly blocking legitimate traffic originating from such prefixes.¶
In general, improper permit of spoofed packets in Source Address Spoofing within a CC scenarios is unavoidable for various uRPF-based methods in partial deployment. For example, consider a topology in which AS 1 and AS 2 are customers of AS 3; and AS 3 is a customer of AS 4. AS 1 and AS 2 originate prefixes P1 and P2, respectively. AS 4 performs SAV on its customer interface with AS 3. P1 and P2 are announced from AS 3 to AS 4 and they would be included in the SAV list (allowlist) of AS 4 with any SAV mechanism. Assume AS 3 doesn't do SAV. Now as an example of Source Address Spoofing within a CC, if AS 2 spoofs AS 1's prefix P1 and sends the spoofed packets to AS 4 (via AS 3), there is no way for AS 4 to detect the spoofed traffic. AS 4's SAV cannot differentiate between the spoofed and the legitimate packets that have source address in P1. In an Source Address Spoofing within a CC scenario of this nature, the only recourse for blocking the spoofed traffic is for AS 3 also to be upgraded to do SAV, i.e., deployment of SAV closer to the source of spoofing.¶
Another scenario is highlighted in Figure 4 while using EFP-uRPF Alg-B method on customer interfaces. This scenario is not Source Address Spoofing within a CC from the perspective of each individual customer interfaces of AS 4, but it is Source Address Spoofing within a CC from the perspective of AS 4 as a whole. EFP-uRPF Alg-B relaxes directionality to reduce (or eliminate) false positives and that makes it more susceptible to Source Address Spoofing within a CC (per the latter perspective). This is expected because EFP-uRPF Alg-B somewhat conservatively applies the same relaxed SAV list across all customer interfaces.¶
+----------------+
| AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 2, AS 1] / | \ \
P1[AS 2, AS 1] / | \ \
P2[AS 2] / | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
Spoofer(P5')-+ AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
\ | \ \
P6[AS 1] \ | \ \
P1[AS 1] \ | \ \
\(C2P) |(C2P) (C2P)\ (C2P)\
+----------------+ +----------------+
| AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P5' is the spoofed source prefix P5 by the spoofer which is inside of
AS 2 or connected to AS 2 through other ASes.
In Figure 4, the source address spoofing takes place within AS 4's CC, where the spoofer, which is inside of AS 2 or connected to AS 2 through other ASes, sends spoofing traffic with spoofed source addresses in P5 to AS 3 along the path AS 2->AS 4-> AS 3. The arrows in Figure 4 illustrate the commercial relationships between ASes. AS 3 serves as the provider for AS 4 and AS 5, while AS 4 acts as the provider for AS 1, AS 2, and AS 5. Additionally, AS 2 is the provider for AS 1. Suppose AS 1 and AS 4 have deployed inter-domain SAV, while the other ASes have not.¶
If AS 4 deploys EFP-uRPF Alg-B at its customer interfaces, it will allow packets with source addresses in P5 to originate from AS 1, AS 2, and AS 5. Consequently, AS 4 will improperly permit the spoofed packets from AS 2, enabling them to propagate further.¶
In the scenario of Figure 4, Strict uRPF, FP-uRPF, and EFP-uRPF Alg-A — applied on the customer interfaces — work effectively to block the spoofed packets from AS 2. This is because these mechanisms have stronger directionality property than EFP-uRPF Alg-B.¶
SAV is used at peer interfaces for validating the traffic entering the validating AS and destined for the AS's customer cone. The data packets received from a customer or lateral peer AS must have source addresses belonging only to the prefixes in the CC of that AS. In both cases, the focus is on discovering all prefixes in the CC of the neighbor AS. So, in principle, the SAV techniques suitable on a customer interface may also be used on a peer interface, especially EFP-uRPF Alg-A or Alg-B, which are more accommodative of asymmetric routing. Indeed, asymmetric routing is thought to be prevalent for peer interfaces. If SAV techniques suitable for customer interfaces are considered for peer interfaces, then the gap analysis of Section 4.1 would also be applicable to the SAV for the peer interfaces. However, due to increased concern about asymmetric routing, network operators may conservatively use the same relaxed SAV techniques for peer interfaces as those for provider interfaces, e.g., Loose uRPF Section 4.3. In that case, the gap analysis of Section 4.3 would also be applicable to the SAV for peer interfaces.¶
SAV is used at provider interfaces for validating the traffic entering the AS and destined for the AS's customer cone. Figure 5 summarizes the gaps of ACL-based ingress filtering and Loose uRPF for SAV at provider interfaces in the scenarios of interest. ACL-based ingress filtering may effectively block spoofing traffic from provider AS, while appropriately allowing legitimate traffic, but it has high operational overhead. On the other hand, Loose uRPF correctly permits legitimate traffic, but it can also mistakenly allow spoofing traffic to pass through.¶
In Figure 5, Spoofing from Providers refers to a scenario in which spoofed traffic comes from provider ASes, either because they generate the spoofed traffic themselves or because they relay spoofed traffic originating from their customers' or peers' respective CCs. The spoofed prefix may belong to (originated by) any AS in the Internet other than the spoofing AS; it may even belong to an AS in the customer cone of the validating AS (example below).¶
+------------------------+------------+---------------+ | Traffic & Scenarios | ACL | Loose uRPF | +----------+-------------+------------+---------------+ |Legitimate| | | Functions | |Traffic | -- | High | as Expected | +----------+-------------+Operational +---------------+ |Spoofed | Spoofing | Overhead | | |Traffic | from | (HOO) |Improper Permit| | | Providers | | | +----------+-------------+------------+---------------+ 'Functions as Expected' connotes the absence of improper block. It also connotes low operational overhead.
Figure 6 illustrates a scenario of Spoofing from Providers and is used to analyze the gaps of ACL-based ingress filtering and Loose uRPF.¶
+----------------+
Spoofer(P1')+-+ AS 3(P3) |
+-+/\----+/\+----+
/ \
/ \
/ \
/ (C2P) \
+----------------+ \
| AS 4(P4) | \
++/\+--+/\+--+/\++ \
P6[AS 2, AS 1] / | \ \
P1[AS 2, AS 1] / | \ \
P2[AS 2] / | \ \
/ (C2P) | \ P5[AS 5] \ P5[AS 5]
+----------------+ | \ \
| AS 2(P2) | | P1[AS 1] \ \
+----------+/\+--+ | P6[AS 1] \ \
\ | \ \
P6[AS 1] \ | \ \
P1[AS 1] \ | \ \
\ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
| AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
P1' is the spoofed source prefix P1 by the spoofer which is inside of
AS 3 or connected to AS 3 through other ASes.
In Figure 6, the spoofer which is inside of AS 3 or connected to AS 3 through other ASes forges the source addresses in P1 and sends the spoofing traffic to the destination addresses in P2 at AS 2. AS 1 is a customer of AS 2; AS 1 and AS 2 are customers of AS 4; AS 4 is a customer of AS 3; and AS 5 is a customer of both AS 3 and AS 4. Suppose AS 4 and AS 1 have deployed inter-domain SAV, while the other ASes have not.¶
Using the ACL method in the form of a disallow (deny) list at the provider interface of AS 4 (facing AS 3) incurs a very high operational overhead, as mentioned in Section 3.¶
Applying Loose uRPF at the provider interface of AS 4 (facing AS 3) can greatly reduce the operational overhead because it uses the FIB as the information source for allowed prefixes, and can adapt to changes in the network to prevent false positives (improper blocking). However, using Loose uRPF at AS 4 will naturally permit packets with source addresses in P1 (since P1 is present in the FIB) and hence will not prevent the improper permit of the spoofed packets from AS 3 Figure 6. This is an expected limitation of Loose uRPF.¶
Figure 7 provides a comprehensive summary of the gap analysis in Section 4. It highlights the scenarios where existing inter-domain SAV mechanisms may encounter issues, including instances of improper blocking of legitimate traffic, improper permitting of spoofing traffic, or high operational overhead. The various entries in the table in Section 4 can be traced back to the terminology and analyses presented in Section 4.¶
+--------+----------+-----------+----------+-------+--------+ |Problems| ACL | Strict | Loose |FP-uRPF|EFP-uRPF| | | | uRPF | uRPF | | | | |(CI or PI)| (CI) | (PI) | (CI) | (CI) | +--------+----------+-----------+----------+-------+--------+ |Improper| YES/NO | YES | NO** | YES | |Block |(manual | (LPP, HP) | | (LPP, HP) | | |operator | | | | | |diligence)| | | | +--------+----------+-----------+----------+-------+--------+ |Improper| YES/NO |NO (no SCC)| YES | NO (no SCC) | |Permit |(manual |YES (SCC) |(Spoofing | YES (SCC) | | |operator | | from | | | |diligence)| |Providers)| | +--------+----------+-----------+----------+-------+--------+ | | YES | | | HOO | (Any | NO | | |Scenarios)| | +--------+----------+---------------------------------------+ CI = Customer Interface PI = Provider Interface HOO = High Operational Overhead LPP = Limited Propagation of a Prefix HP = Hidden Prefix SCC = Spoofing within a CC ** Typically, an HP (like DSR prefixes) is hidden on the CIs but received on a provider or peer interface; hence included in the FIB and that helps avoid improper block for Loose uRPF.
The problem statement that results from the gap analysis can be expressed as follows. New proposals for SAV should aim to fill in the following problem areas (gaps) found in the currently standardized SAV methods (found in IETF RFCs):¶
Improper block: Existing uRPF-based mechanisms suffer from improper block (false positives) in two inter-domain scenarios: Limited Propagation of a Prefix (e.g., NO_EXPORT and some other selective-export scenarios) and Hidden Prefix (e.g., CDN/DSR scenario).¶
Improper permit: With some existing uRPF-based SAV mechanisms, improper permit (false negatives) can happen on any type of interface (customer, lateral peer, or provider). Specifically, if the method relaxes the directionality constraint [RFC3704] [RFC8704]} to try to achieve zero improper blocking, the possibility of improper permit increases. (Note: It is recognized that unless there is full adoption of SAV in the CC of the interface in consideration, improper permit is not fully preventable in scenarios where source address spoofing occurs from within the CC, i.e., a prefix at one AS in the CC is spoofed from another AS in the same CC.)¶
High operational overhead: ACL-based ingress SAV filtering introduces significant operational overhead, as it needs to update ACL rules manually to adapt to prefix or routing changes in a timely manner. The high operational overhead issue does not pertain to existing uRPF-based mechanisms.¶
The limitations of existing uRPF-based mechanisms are due to their exclusive reliance on BGP data. Although the algorithms themselves have evolved (e.g., [RFC8704]), the underlying input has remained unchanged, inherently constraining their accuracy in scenarios such as LPP and HP. With the availability of authoritative SAV-related information, plus the potential SAV-specific information (Section 2), it would be possible to develop comprehensive new SAV algorithms or mechanisms to overcome the existing gaps.¶
This section lists the requirements for any new inter-domain SAV mechanisms which may be proposed to bridge the technical gaps of existing mechanisms.¶
Any new inter-domain SAV mechanism MUST NOT be worse than existing inter-domain SAV mechanisms in terms of improper block and improper permit. It SHOULD avoid improper blocking and improve the directionality of filtering (i.e., rejecting spoofed traffic). The requirement applies for all directions of AS peering (customer, provider, and peer).¶
Any new inter-domain SAV mechanism SHOULD be able to automatically adapt to network dynamics and asymmetric routing scenarios. Any such solution MUST have less operational overhead than ACL-based ingress SAV filtering.¶
Any new solution MUST NOT assume pervasive adoption of the SAV method, the SAV-related information, or the SAV-specific information. It SHOULD benefit early adopters by providing effective protection from spoofing of source addresses even in partial deployment.¶
SAV-related information, e.g., routing information and RPKI objects, may be used to design more accurate SAV mechanisms. Such information must be protected during both its creation and dissemination (the BGP security community is already diligent about this). If any proposed new SAV method requires exchanging SAV-specific information between ASes, security mechanisms must exist to prevent malicious injection or alteration of the SAV-specific information.¶
Any new inter-domain SAV mechanism SHOULD be responsive to changes in the SAV-related information or the SAV-specific information. It SHOULD automatically update the SAV list while achieving efficient re-convergence of the same. In this context, convergence refers to the stabilization of the SAV lists on the AS-to-AS interfaces performing SAV. It is essential that any new SAV mechanism converges to the correct updated SAV list in a proper manner, minimizing both improper block and improper permit during the process.¶
Any new inter-domain SAV mechanisms should work in the same Internet Protocol (IP) address scenarios as existing SAV methods do. Generally, it includes all IP-encapsulated scenarios:¶
Native IP forwarding: This includes both the global routing table based forwarding and Customer Edge (CE) site forwarding of VPN traffic.¶
IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): In this scenario, the focus is on the validation of the outer layer IP source address.¶
Both IPv4 and IPv6 addresses.¶
The scope does not include:¶
Non-IP packets: This includes MPLS label-based forwarding and other non-IP-based forwarding.¶
In addition, any new inter-domain SAV mechanisms should avoid packet modification in the data plane. Existing architectures or protocols or mechanisms can be inherited by any such mechanism to achieve better SAV effectiveness.¶
The SAV list will be generated based on SAV-related information and/or SAV-specific information. If the information is poisoned by attackers, the SAV list will be inaccurate. Legitimate packets may be dropped improperly or malicious traffic with spoofed source addresses may be permitted improperly. BGP routing security using available methods for the prevention, detection, and mitigation of route hijacks, route leaks, and AS_PATH manipulations should be deployed which leads to greater accuracy of the routing information (e.g., RIB and FIB) in the SAV-related information used for computing SAV lists.¶
This document does not request any IANA allocations.¶
Nan Geng
Huawei
Beijing,
China
Email: gengnan@huawei.com¶
Many thanks to Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Ron Bonica, Aijun Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, John O'Brien, Roland Dobbins, Paul Vixie, Amir Herzberg, Jeffrey Haas, and Xueyan Song for their reviews, comments, and suggestions. Apologies to any others whose names the authors may have inadvertently missed mentioning.¶