]> 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 to use Source Prefix Advertisement (SPA) messages for advertising hidden source prefixes and discovering the hidden paths of source prefixes. The accuracy of existing inter-domain SAV mechanisms like EFP-uRPF can be improved by SPA.

Introduction EFP-uRPF is a promising inter-domain Source Address Validation (SAV) mechanism and works well in most cases. does an analysis of existing inter-domain SAV mechanisms including EFP-uRPF. The analysis shows that EFP-uRPF may have improper blocking problems in the scenarios of i) "hidden source prefixes" in the Direct Server Return (DSR) scenario (see section 4.1.2 of ) and ii) "hidden paths of source prefixes" caused by "Limited Propagation of Prefixes" (see section 4.1.1 of ). The source prefix allowlists at customer-facing or lateral peer-facing interfaces are built by EFP-uRPF primarily based on the local BGP routing information. When source prefixes or paths are "hidden" in normal BGP Update messages, EFP-uRPF will fail to generate accurate prefix allowlists. This document follows the idea of sharing SAV-specific information between ASes proposed in . A new inter-domain message called Source Prefix Advertisement (SPA) is defined. SPA messages can help advertise hidden source prefixes and discover hidden paths, and thus improve the accuracy of existing inter-domain SAV mechanisms like EFP-uRPF. SPA messages can be possibly delivered by extended BGP messages, but the design of protocol extensions are not the focus of this document.

Terminology SPA: Source Prefix Advertisement (SPA) for advertising the origin source prefixes of an AS. Source AS: The AS which originates SPA messages. Validating AS: The AS which receives SPA messages, generates SAV rules, and conducts source address validation.

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 A new inter-domain message called SPA message is defined in this section. An SPA message SHOULD include the following items:

• Source Prefixes: The source prefixes that the source addresses of the locally originated data packets of Source AS belong to. These source prefixes are to be updated or withdrawn, which is indicated by the Update/Withdraw Flag. The updated source prefixes are incremental to the previously announced prefixes.
• Source AS Number: The AS number of the Source AS (aka origin AS) that originates data packets with the source addresses belonging to the Source Prefixes.
• AS Path: It has the same meaning as the AS_PATH attribute in BGP .
• Update/Withdraw Flag: It indicates whether the Source Prefixes in the message are to be updated or withdrawn.

A Source AS can advertise its "hidden source prefixes" through SPA messages to its neighboring ASes. The neighboring ASes can further propagate the messages to next-hop ASes, and so do the next-hop ASes. The manner of the propagation is similar to that of BGP Updates. In the DSR scenario, the anycast prefixes, which are not in the BGP routes originated by the Source AS, can be advertised to remote Validating ASes through SPA messages.

Inter-domain Source Path Discovery SPA messages can be used for source path discovery at the same time as advertising source prefixes. In the "Limited Propagation of Prefixes" scenarios (see section 4.1.1 of ), the propagation of BGP Update messages may be limited due to routing propagation policies (e.g., NO_EXPORT), but the SPA messages will be propagated because they are separate from routing Updates and do not have NO_EXPORT attached. Thus, the "hidden paths of source prefixes" can be discovered through SPA messages by the Validating ASes.

EFP-uRPF Enhanced by SPA This section describes how to use SPA for enhancing EFP-uRPF.

"Hidden Prefixes" Scenario Consider the "Hidden Prefixes" scenario (e.g., the DSR scenario) described in section 4.1.2 of . shows an example of the DSR scenario, which is similar to Figure 3 in . The propagation of BGP Updates of P1, P3 and P6 are shown in the figure. The anycast server in AS3 receives requests from users and tunnels the requests to the edge server in AS1. Then, the edge server will respond directly to the users by using the anycast IP address (belonging in P3) as the source address in the response packets. Prefix P3 is the anycast prefix and is only advertised by AS3 through BGP. Suppose AS2 or AS4 enables EFP-uRPF at customer-facing interfaces. The packets with source addresses belonging in P3 sent by AS1 will be blocked improperly when the packets arrive at the customer-facing interfaces of AS2/AS4. In this example, P3 is the hidden source prefix of AS1.

An example of the DSR scenario.

SPA can be used to solve the improper blocking problems in the "Hidden Prefixes" scenarios. In the above DSR scenario, AS1 can advertise the hidden source prefix P3 to Validating ASes (i.e., AS2 and AS4) through SPA messages. The propagation process of SPA messages is illustrated in . After receiving the SPA message, AS2 and AS4 will take a union of the prefixes in the SPA messages and the BGP Update messages for constructing SAV tables (allowlists). As a result, P3 will be included in the source prefix allowlist at the customer-facing interfaces at AS2 and AS4. When AS1 sends packets with source address in P3, they will pass the validation at AS2 and AS4.

SPA for the DSR scenario.

"Limited Propagation of Prefixes" Scenario Consider the "Limited Propagation of Prefixes" scenario (e.g., the NO_EXPORT scenario) described in section 4.1.1 of . shows the NO_EXPORT scenario, which is similar to Figure 2 in . AS1 advertises only prefix P1 to AS2 through a BGP Update message with the NO_EXPORT community. As a result, AS4 learns no route of AS1 directly from AS2. If AS4 enables EFP-uRPF with algorithm A at the customer-facing interface connected to AS2, the packets with source addresses in P1 or P6 will be blocked improperly.

An example of the NO_EXPORT scenario.

SPA can be used to solve the improper blocking problems in the "Limited Propagation of Prefixes" scenarios. In the above NO_EXPORT scenario, AS1 can send an SPA message to AS2, and then AS2 will propagate the message to AS4. Note that NO_EXPORT community does not apply and never attached to SPA messages. The propagation process of SPA messages is illustrated in . AS4 deploying EFP-uRPF with either Algorithm A or Algorithm B will learn the existence of AS1 from the interface connected to AS2. AS4 will take the union of prefixes (and also AS paths) learned from BGP and SPA messages. Thus AS4 will include the source prefixes P1 and P6 of AS1 in the source prefix allowlist for the interface with AS2. When data packets with source addresses in P1 or P6 arrive at AS4 via AS2, they will pass the validation at AS4.

SPA for the NO_EXPORT scenario.

Convergence Considerations Validating AS needs to update SAV rules when source prefixes of Source AS or the paths of source prefixes change. The following RECOMMENDED actions will result in more effective re-convergence:

• Applying hysteresis in the case of withdrawal of source prefixes or paths of source prefixes: During the re-convergence, the SAV source prefix lists will include some withdrawn prefixes for a little longer, and there may exist improper permitting shortly but no improper blocking.
• Updating source prefixes or paths of source prefixes as soon as possible when SPA message is received: During the convergence, any possibility of improper blocking will be minimized or eliminated if new source prefixes are announced in SPA first and then some delay is allowed before the related services (utilizing the new source prefixes) are activated online.

Security Considerations There are two main threats associated with SPA: prefix hijacking and path hijacking.

• Prefix hijacking. A malicious AS may send an SPA message which hijacks the source prefixes of a Source AS. The Validating AS that receives the message may improperly include the source prefixes in some source prefix lists, which results in improper permitting but no improper blocking.
• Path hijacking. A malicious AS may send an SPA message which carries a manipulated AS_PATH, which can be a forged-origin attack or a forged-path-segment attack. The Validating AS that receives the message may improperly include the source prefixes in some source prefix lists, which results in improper permitting but no improper blocking.

Existing mechanisms for detecting and preventing BGP prefix hijacking and BGP path hijacking can be used to deal with the above two threats.

IANA Considerations There is no IANA requirement.

Acknowledgements Many thanks to the comments from XXX.

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 Tsinghua University 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. Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory Zhongguancun Laboratory 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 This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK]