| Internet-Draft | SPA for Inter-domain SAVNET | July 2026 |
| Geng, et al. | Expires 24 January 2027 | [Page] |
This document proposes a mechanism that enables a Source AS to actively advertise their locally observed Customer Cone and prefix information to the adjacent Validating AS via a new inter-domain message called Source Prefix Advertisement (SPA). The Validating AS then combines this SPA-carried information with local source address validation-related information to construct more accurate prefix allowlists for interfaces connected to Source ASes.¶
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 24 January 2027.¶
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.¶
The techniques like EFP-uRPF [RFC8704] perform effective source address filtering on customer interfaces and lateral peer interfaces. It constructs a source prefix allowlist for each customer or lateral peer interface based on the BGP [RFC4271] routes received by the local AS. Data packets received from a customer or lateral peer are only permitted if their source addresses fall within the Customer Cone of that neighbor. The enforcement is thus strictly limited to the Customer Cone of the respective neighbor, which includes the AS and the prefixes originated or delegated by the customer or lateral peer.¶
Building an accurate prefix set representing the Customer Cone is therefore critical to the correct operation of these source address validation mechanisms. However, a locally constructed Customer Cone prefix set may not be accurate and can differ from the actual Customer Cone prefix set observed by the neighbor (i.e., the customer or lateral peer). This discrepancy can arise due to various factors, including BGP no-export communities, Direct Server Return (DSR), complex inter-domain commercial relationships (e.g., partial transit relationships), and other routing policy differences. Such inaccuracies may result in false positives (legitimate packets being incorrectly filtered) or false negatives (illegitimate packets being incorrectly allowed), which degrade the effectiveness and dependability of the source address validation mechanism. A concrete analysis of existing inter-domain Source Address Validation (SAV) mechanisms can be found in [I-D.ietf-savnet-inter-domain-problem-statement].¶
To improve the accuracy of SAV, this document proposes a mechanism called Inter-domain Source Prefix Advertisement (SPA). A neighboring AS (either a customer or a lateral peer) actively advertise the prefix information and Customer Cone information that it observes locally. The advertised information known helps the local AS construct a more accurate prefix allowlist on the corresponding customer or lateral peer interface. This mechanism follows the idea presented in [I-D.ietf-savnet-inter-domain-architecture] regarding the exchange of SAV-specific information between ASes. To carry the SAV-specific information between ASes, a new inter-domain SPA message is defined.¶
Protocol definitions or protocol extensions for the mechanism proposed in this document are out of scope.¶
Source Prefix Advertisement (SPA): The process that an AS can actively advertise the prefix information and Customer Cone information that it observes locally to a neighboring AS through the messages called SPA messages.¶
Source AS: The AS which originates SPA messages to the Validating AS. A Source AS is typically the customer or lateral peer of the Validating AS.¶
Validating AS: The AS which receives SPA messages from the Source AS, generates SAV rules, and conducts source address validation. Validating AS is typically the provider or lateral peer of the Source AS.¶
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.¶
Assume that a Validating AS has deployed inter-domain SAV mechanisms (e.g., EFP-uRPF [RFC8704]) on its customer-facing interfaces or lateral peer-facing interfaces, which enables it to build a prefix allowlist on such interfaces. Leveraging the SPA mechanism, the Source AS can assist the Validating AS in constructing a more accurate prefix allowlist. This document does not restrict the specific mechanism adopted by the Validating AS to generate the prefix allowlist, and it elaborates on the inter-domain SPA mechanism taking the Validating AS deploying EFP-uRPF as an example.¶
The inter-domain SPA mechanism proposed in this document generally consists of the following three steps:¶
+-----------------+
| Validating AS | Step3: Constrcut prefix allowlist
+------+/\+-------+ by combining EFP-uRPF and SPA
|
|
| Step2: Advertise SAV-specific information through
| SPA messages
|
+-----------------+
| Source AS | Step1: Construct SAV-specific information
+-----------------+
SPA messages serve two distinct purposes:¶
First, the Source AS can utilize SPA to supplement customer cone information and source prefix information. When constructing the prefix allowlist for a corresponding interface, the Validating AS adds prefixes indicated by SPA messages to the allowlist, generating a more comprehensive prefix allowlist and mitigating improper filtering legitimate traffic (i.e., improper block problems or false positives).¶
Second, SPA can be used for exclusion. The Source AS may send SPA messages to exclude specific customer cone members or source prefixes. While building the interface-specific prefix allowlist, the Validating AS removes inappropriate prefixes from the allowlist based on SPA-transmitted data. This yields a more accurate prefix allowlist and prevents improper acceptance of illegitimate traffic (i.e., improper permit problems or false negatives).¶
This subsection describes how to leverage SPA to supplement source prefixes into the prefix allowlist.¶
The Source AS constructs the Customer Cone and its corresponding prefix set based on its local observations, with specific considerations for the following factors to ensure the comprehensiveness and accuracy of the constructed set:¶
Step 1.1: The Source AS constructs the Customer Cone (which includes itself) and the corresponding prefix set by integrating multiple authoritative data sources, primarily including local BGP routing information and RPKI data. This integration ensures that the prefix set is initially grounded in verifiable and widely-recognized routing and resource validation information.¶
Step 1.2: For prefixes hidden in the DSR scenarios where prefixes that are not propagated through standard BGP routing and thus not captured by the above data sources, the Source AS adds such hidden prefixes to the constructed prefix set through administrative configuration. This step addresses the invisibility of DSR-related prefixes in normal routing propagation, preventing their omission from the Customer Cone.¶
Step 1.3: If the Source AS itself acts as a Validating AS for its downstream neighboring ASes (which serve as Source ASes relative to it), it incorporates the prefix information carried in the SPA messages received from these downstream Source ASes. By integrating this SPA-sourced information with the locally derived Customer Cone and prefix data, the Source AS constructs a complete and accurate prefix set that reflects both its own resource scope and the valid prefixes of its downstream neighbors.¶
The Source AS generates SPA messages — a new inter-domain message specifically defined in this document to carry Customer Cone and prefix information between ASes — and advertises the locally observed Customer Cone and its corresponding prefix set to the adjacent Validating AS (the AS responsible for performing source address validation on the interface connecting the two ASes). The detailed implementation of this step is as follows:¶
The Source AS may transmit the following required information to the Validating AS via one or more SPA messages:¶
The set of AS numbers belonging to the Customer Cone observed locally by the Source AS. This set includes the Source AS itself and all ASes within its Customer Cone, providing the Validating AS with the hierarchical scope of the Source AS's Customer Cone.¶
The source prefix set of the Customer Cone observed locally by the Source AS. This set comprises all valid prefixes originated, delegated, or associated with the Customer Cone (including DSR-hidden prefixes added via administrative configuration, as specified in Step 1).¶
The AS number of the Source AS. This field serves as an identifier to enable the Validating AS to associate the received SPA message with the correct neighboring AS and the corresponding interface, avoiding confusion when multiple neighbors send SPA messages.¶
An Update/Withdraw Flag. This flag is used to explicitly indicate whether the information carried in the SPA message is intended to update the existing Customer Cone or prefix set information (Update Flag) or to withdraw previously advertised Customer Cone or prefix set information (Withdraw Flag). This ensures the Validating AS can dynamically maintain the accuracy of its prefix allowlists as the Source AS's Customer Cone changes over time.¶
In practice, the Source AS does not need to advertise complete customer cone and prefix information to the Validating AS via SPA messages, since most of such information has already been announced through the eBGP session established between the two ASes. The Source AS can identify the supplementary information required by the peer based on its local RIB-Out, and only carry this supplementary information within SPA messages, thereby eliminating unnecessary transmission overhead.¶
Upon receiving SPA messages from the Source AS, the Validating AS may propagate the received Customer Cone and prefix information within its own AS. However, the Validating AS MUST NOT propagate the received SPA messages to other ASes.¶
It should be noted that detailed implementation aspects such as the specific session establishment method between the Source AS and the Validating AS, potential capability negotiation processes (e.g., confirming support for SPA messages), and the encapsulation format of SPA messages are out of the scope of this document and shall be defined in subsequent protocol extension documents.¶
The Validating AS constructs an accurate prefix allowlist for the interface connecting to the Source AS, following the core logic of the EFP-uRPF algorithm [RFC8704] and integrating the information received from SPA messages. The detailed implementation of this step is as follows:¶
Step 3.1: The Validating AS enables the EFP-uRPF algorithm on the specific interface through which it receives SPA messages from the Source AS. This ensures that the source address validation mechanism is activated for the connection to that neighbor, aligning with the foundational approach of EFP-uRPF for customer and lateral peer interfaces.¶
Step 3.2: The Validating AS merges two sets of information to form a complete and accurate prefix set for the interface: one is the Customer Cone and its corresponding prefix set generated locally by the Validating AS in accordance with the EFP-uRPF algorithm specified in [RFC8704] (integrating local BGP routing information, RPKI data, and other relevant sources); the other is the Customer Cone and prefix set information carried in the SPA messages advertised by the Source AS.¶
This merging process supplements the locally generated prefix set with the Source AS's observed Customer Cone and prefix information—information that the Validating AS may not be able to obtain through existing mechanisms due to factors such as BGP no-export communities or DSR. As a result, the combined prefix set becomes more comprehensive and accurate, effectively mitigating the risks of false positives and false negatives caused by incomplete locally constructed Customer Cone prefix sets.¶
This subsection describes how to leverage SPA to exclude source prefixes from the prefix allowlist.¶
A typical application scenario for this usage involves partial transit services. Specifically, a customer AS under the Source AS may purchase partial transit services for certain address prefixes from the Source AS. Traffic related to these address prefixes is only forwarded within the Customer Cone of the Source AS and will not access the external Internet through the connection between the Source AS and the Validating AS.¶
In this scenario, the Source AS will not advertise these address prefixes to the Validating AS via BGP, as the partial transit service does not require propagating these prefixes to the external Internet. However, the Validating AS may still include these prefixes in the prefix allowlist of the interface connected to the Source AS. This can occur in two common cases: first, the customer AS of the Source AS may advertise these prefixes through other ASes, which are then propagated to the Validating AS; second, the customer AS may have registered RPKI ROA data for these prefixes, which the Validating AS obtains and uses to construct the prefix allowlist [I-D.ietf-sidrops-bar-sav].¶
To address this issue, the Source AS can advertise an SPA message carrying these specific address prefixes, explicitly instructing the Validating AS not to include these prefixes in the source prefix allowlist of the connected interface. This approach offers a key benefit: if the Source AS inadvertently leaks the prefixes related to the partial transit service, or if forged traffic using these prefixes originates within the Source AS's Customer Cone and is sent to the external Internet, the Validating AS can effectively intercept such traffic by excluding these prefixes from the allowlist, thereby enhancing the security of inter-domain source addresses.¶
The Source AS requires global visibility of its own AS to construct a complete customer cone and prefix set. Retrieval of such global information may rely on a controller or protocols (e.g., BMP). Algorithms for constructing customer cones and prefix sets can follow those defined in EFP-uRPF or BAR-SAV but may need to be extended. Accordingly, the operational considerations specified in [RFC8704] and [I-D.ietf-sidrops-bar-sav] are also applicable to this document.¶
The Source AS must detect updates to SAV-specific information in real-time and promptly notify the Validating AS of such changes. Meanwhile, the Validating AS must be capable of updating its local prefix allowlist in a timely manner upon receiving the updated information.¶
A negotiable session should be established between the Source AS and the Validating AS to enable reliable delivery of SPA messages.¶
The mechanism proposed in this document operates between adjacent ASes. For the secure exchange of SPA messages between the Source AS and the Validating AS, existing BGP session protection mechanisms can be adopted, including GTSM/TTL-security [RFC5082], BGP-MD5, and TCP-AO [RFC5925]. These mechanisms help ensure the confidentiality, integrity, and authenticity of SPA messages, preventing unauthorized tampering, eavesdropping, or spoofing of the message content during transmission. More Detailed guidelines can be found in Section 5 of [RFC7454] and Section 3 of [I-D.ietf-grow-bgpopsecupd].¶
The information advertised by the Source AS via SPA messages directly determines whether the legitimate traffic sent from the Source AS to the Validating AS can pass source address validation, as well as whether attacks originating from the Source AS can be effectively intercepted by the Validating AS. The Source AS has little incentive to intentionally advertise incorrect or malicious SPA information. Any false or malicious SPA advertisements would either result in legitimate traffic from the Source AS being incorrectly filtered (a false positive) or fail to intercept attacks originating from the Source AS (a false negative)—both of which are detrimental to the Source AS's own network connectivity and security.¶
There may exist a potential security risk: a Source AS may craft SPA messages claiming to add certain source prefixes to the allowlist. Such forged SPA messages could directly cause the adjacent Validating AS to loosen source prefix validation, and indirectly degrade the validation accuracy of upstream Validating ASes. Adversaries may exploit this fabricated SPA information to launch malicious attacks.¶
Operational measures should be adopted by the Source AS to prevent such incidents. Nevertheless, if a Source AS deliberately generates malicious SPA messages, once such attacks are detected, we can substantiate that the Source AS intentionally produced fraudulent SPA payloads rather than suffering from unintended misconfiguration. Upon confirmation, the Validating AS will revoke its trust in the offending Source AS. Attacks of this kind are discrete incidents with definitive audit trails for accountability. In contrast, conventional DDoS attackers cannot collude with operators of legitimate Source AS networks. Therefore, the mechanism specified in this document remains robust and effective under most conventional deployment scenarios.¶
If the mechanism is deployed within a single trusted domain, many of the aforementioned security risks can be mitigated. Within a trusted administrative domain, all participating ASes are under unified governance and consistent security policies, which eliminates the incentive and opportunity for autonomous systems to deliberately forge malicious SPA messages.¶
There is no IANA requirement.¶
Thanks a lot for the comments from Jeff Hass, Igor Lubashev, and Joel Halpern.¶