]> Huawei

Beijing China gengnan@huawei.com

Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

USA NIST

Gaithersburg, MD 20899 United States of America ksriram@nist.gov

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Routing SAVNET Internet-Draft This document proposes a mechanism that enables neighboring ASes (Source ASes) to actively advertise their locally observed Customer Cone and prefix information 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.

Introduction The EFP-uRPF technique performs 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 Customer Cone of the neighboring 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 . To address this problem, 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 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 regarding the exchange of SAV-specific information between ASes. To carry such source prefix information between ASes, a new inter-domain SPA message is defined. Protocol extensions for the mechanism proposed in this document are out of scope.

Terminology 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. Source AS is typically the customer or lateral peer of 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 Source AS.

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.

Inter-domain Source Prefix Advertisement The mechanism proposed in this document generally consists of the following three steps:

An overview of the inter-domain SPA mechanism.

Step 1: Construct Customer Cone and Prefix Set at Source AS First, the neighboring AS, referred to as 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.

Step 2: Advertise Customer Cone and Prefix Set through SPA Second, 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.

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.

Step 3: Construct Prefix List by Combining EFP-uRPF and SPA Third, 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 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 (or some other algorithms like BAR-SAV ) 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 (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.

Special Usage of Inter-domain SPA In the descriptions above, the information carried in SPA messages is merged into the information generated by the EFP-uRPF algorithm to enhance the comprehensiveness of the prefix allowlist. This section introduces a special usage of SPA messages: the Source AS may advertise SPA messages to instruct the Validating AS to remove specific AS numbers or source prefixes from the information generated by the EFP-uRPF algorithm on the corresponding interface. A typical application scenario for this special 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. 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 address.

Operational and Deployment Considerations TBD

Security Considerations 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 , BGP-MD5, and TCP-AO . 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 and Section 3 of . Notably, the scope of influence of the Source AS is strictly limited to the prefix allowlist of the interface on the Validating AS that is directly connected to the Source AS. 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. This limited scope of influence inherently mitigates the risk of malicious behavior by the Source AS. Specifically, 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.

IANA Considerations There is no IANA requirement.

Acknowledgements Thanks a lot for the comments from Jeff Hass and Igor Lubashev.

References Normative References This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology 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 document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References USA National Institute of Standards and Technology Akamai Technologies USA National Institute of Standards and Technology Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK] This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing. Max-Planck-Institut fuer Informatik Internet Neutral Exchange Association The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability requirements that can and should be ensured to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publications of RFC7454, several developments and changes in operational practice took place that warrant an update of these best current practices. This document obsoletes RFC7454, focusing on the overall goals, and providing a less implementation centric set of best practices. This document describes security requirements and goals when operating BGP for exchanging routing information with other networks, and explicitly does not focus on specific technical implementations and requirements.