]> Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Zhongguancun Laboratory

Beijing China qinlc@zgclab.edu.cn

Zhongguancun Laboratory

Beijing China liulb@zgclab.edu.cn

Huawei

Beijing China huangmingqing@huawei.com

USA National Institute of Standards and Technology

Gaithersburg MD United States of America sriram.ietf@gmail.com

General [REPLACE] Internet Engineering Task Force 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.

Introduction Source address validation (SAV) is crucial for protecting networks from source address (SA) spoofing attacks . The MANRS initiative advocates deploying SAV as close to the source as possible , and access networks are the first line of defense against source address spoofing. However, access networks face various challenges in deploying SAV mechanisms due to different network environments, router vendors, and operational preferences. Hence, SAV may not be deployed ubiquitously in access networks. In addition, SA spoofing may also originate in ISP networks at higher levels of hierarchy in the Internet. So, deployment of SAV mechanisms in the edge routers of enterprises as well as the ISP networks (at different hierarchichal levels or tiers) is needed to prevent source address spoofing along the data forwarding paths. highlights the importance of SAV at various network locations: access, intra-domain (intra-AS), and inter-domain (inter-AS). This document focuses on providing gap analysis and describing the problem space of existing inter-domain SAV solutions, and defining the requirements for a new solution of these problems. Access Control List (ACL) and unicast Reverse Path Forwarding (uRPF) techniques are currently utilized for inter-domain SAV . Here only existing IETF RFCs are considered as the state of the art (BCP 38 and BCP 84 ); IETF works-in-progress are not included in that. 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 . Further, mentions Route Server (RS) and RS-client. An RS-to-RS-client interface is akin to a customer interface, and an RS-client-to-RS interface is akin to a provider interface for the purposes of SAV. There are several existing mechanisms for inter-domain SAV. This document analyzes them and attempts to answer: i) what are the technical gaps (), ii) what are the fundamental problems (), and iii) what are the practical requirements for the solution of these problems (). The following summarizes the fundamental problems with existing SAV mechanisms, as analyzed in and :

• Improper block: Existing uRPF-based mechanisms suffer from improper block (false positives) in two inter-domain scenarios: limited propagation of prefixes and hidden prefixes.
• Improper permit: With some existing uRPF-based SAV mechanisms, improper permit (false negatives) can happen on any type interface (customer, lateral peer, or provider). Specifically, if the method relaxes the directionality constraint } 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 prevented 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 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.

To address these problems, in , this document outlines the following technical requirements for a new solution:

• Improved SAV accuracy over existing mechanisms: A new solution MUST avoid improper block and minimize improper permit.
• Reduced operational overhead: A new solution MUST have less operational overhead than ACL-based ingress SAV filtering.

In addition, this document defines three more requirements to ensure practicality:

• Benefit in incremental/partial deployment: A new solution MUST NOT assume pervasive adoption including the adoption of both SAV method and SAV-related information (e.g., RPKI object registrations) and SHOULD provide benefit to early adopters in terms of effective SAV performance.
• Providing necessary security guarantee: For solutions involving communication of new SAV-specific information between ASes, there SHOULD be a security mechanism assuring trustworthiness of the information.
• Efficient convergence: A new solution SHOULD achieve efficient SAV rule (SAV table) convergence in response to prefix or route changes.

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.

Terminology

SAV Rule:

The rule that indicates the validity of a specific source IP address or source IP prefix.

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.

Existing Inter-domain SAV Mechanisms 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 , which are reviewed in this section.

• ACL-based ingress filtering : ACL-based ingress SAV filtering is a technique that relies on ACL rules to filter packets based on their source addresses. It can be applied at provider interfaces, lateral peer interfaces, or customer interfaces of an AS, and is recommended for deployment at provider interfaces . At the provider interfaces, ACL-based ingress SAV filtering can block source prefixes that are clearly invalid in the inter-domain routing context, such as IANA special purpose or unallocated IPv4/IPv6 prefixes and the AS's internal-only prefixes. 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. It is also impractical to store a very large and dynamically varying unallocated IPv6 prefixes. At the customer interfaces, ACL-based ingress filtering is less desirable. Other techniques (as described below) are more effective for ingress SAV filtering on customer interfaces. 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.
• uRPF-based mechanisms: A class of SAV mechanisms are based on Unicast Reverse Path Forwarding (uRPF) . 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 holds in practice, and to address cases where it does not hold, many enhancements and modes of uRPF are proposed. Different modes of uRPF have different levels of strictness and flexibility, and network operators can choose from them to suit particular network scenarios. We describe these modes as follows:
  • Strict uRPF : Strict uRPF is the most stringent mode, and it only permits packets that have a source address that is covered by a prefix in the FIB, and that the next hop for that prefix is the same as the incoming interface. This mode is recommended for deployment at customer interfaces that directly connect to an AS with suballocated address space, as it can prevent spoofing attacks from that AS or its downstream ASes .
  • Loose uRPF : Loose uRPF verifies that the source address of the packet is routable in the Internet by matching it with one or more prefixes in the FIB, regardless of which interface the packet arrives at. 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 in prefixes that are not routed in the global Internet (e.g., IANA allocated private-use addresses, multicast addresses, etc.) .
  • Feasible Path uRPF (FP-uRPF) : maintains a reverse path forwarding (RPF) list, which contains the prefixes and all their permissible routes including the optimal and alternative ones. It permits an incoming packet only if the packet's source address is encompassed in the prefixes of the RPF list and its incoming interface is included in the permissible routes of the corresponding prefix. FP-uRPF is recommended to be deployed at customer interfaces or lateral peer interfaces, especially those that are connected to multi-homed customer ASes .
  • Virtual routing and forwarding (VRF) uRPF : VRF uRPF uses a separate VRF table for each external BGP peer and is only a way of implementation for a SAV table.
  • Enhanced Feasible Path uRPF (EFP-uRPF) : EFP-uRPF is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces. The EFP-uRPF specification provides two alternate algorithms: Algorithm A which is stricter with a greater sense of directionality and Algorithm B which is more permissive with a lesser sense of directionality. EFP-uRPF can more effectively accommodate asymmetric routing scenarios than FP-uRPF. EFP-uRPF is a part of BCP84. EFP-uRPF can be used at customer as well as lateral peer interfaces of an AS. It is not deployed yet in the Internet.
• Carrier Grade NAT (CGN): CGN is a network technology used by service providers to translate between private and public IPv4 addresses within their network. CGN enables service providers to assign private IPv4 addresses to their customer ASes instead of public, globally unique IPv4 addresses. The private side of the CGN faces the customer ASes, and when an incoming packet is received from a customer AS, CGN checks its source address. If the source address is included in the address list of the CGN's private side, CGN performs address translation. Otherwise, it forwards the packet without translation. However, since CGN cannot determine whether the source address of an incoming packet is spoofed or not, additional SAV mechanisms need to be implemented to prevent source address spoofing .

Gap Analysis Inter-domain SAV is essential in preventing source address spoofing traffic across all AS interfaces, including those of customers, providers, and lateral peers. An ideal inter-domain SAV mechanism MUST block all spoofing traffic while permitting legitimate traffic in all scenarios. 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 used in the corresponding interfaces of these scenarios to identify their technical limitations.

SAV at Customer Interfaces SAV is used at customer interfaces to validate traffic from the customer cone, including both legitimate traffic and spoofing traffic. To prevent the source address spoofing, operators can enable ACL-based ingress filtering and/or uRPF-based mechanisms at customer interfaces, namely Strict uRPF, FP-uRPF, or EFP-uRPF. However, uRPF-based mechanisms may cause improper block problems in two inter-domain scenarios: limited propagation of prefixes and hidden prefixes, or may cause improper permit problems in the scenarios of source address spoofing within a customer cone, while ACL-based SAV ingress filtering needs to update SAV rules in a timely manner and lead to high operational overhead.

The gaps of ACL-based ingress filtering, Strict uRPF, FP-uRPF, and EFP-uRPF in the scenarios of interest.

provides an overview of the gaps associated with ACL-based ingress filtering, Strict uRPF, FP-uRPF, and EFP-uRPF for SAV at customer interfaces in the corresponding scenarios. ACL-based ingress filtering has high operational overhead as performing SAV at customer interfaces. Strict uRPF, FP-uRPF, and EFP-uRPF, on the other hand, may incorrectly block legitimate traffic in the scenarios of limited propagation of prefixes or hidden prefixes. Furthermore, in the scenarios of source address spoofing within a customer cone, EFP-uRPF with algorithm B may inadvertently permit the spoofing traffic. In the following, we analyze the gaps of Strict uRPF, FP-uRPF, and EFP-uRPF for SAV at customer interfaces in scenarios of limited propagation of prefixes, hidden prefixes, and source address spoofing within a customer cone, respectively.

Limited Propagation of Prefixes In inter-domain networks, some prefixes may not be propagated to all domains due to various factors, such as NO_EXPORT or NO_ADVERTISE communities or other route filtering policies. This may cause asymmetric routing in the inter-domain context, which may lead to improper block when performing SAV with existing mechanisms. These mechanisms include EFP-uRPF, which we focus on in the following analysis, as well as Strict uRPF and FP-uRPF. All these mechanisms suffer from the same problem of improper block in this scenario.

Limited propagation of prefixes caused by NO_EXPORT.

presents a scenario where the limited propagation of prefixes occurs due to the NO_EXPORT community attribute. In this scenario, AS 1 is a customer of AS 2, AS 2 is a customer of AS 4, AS 4 is a customer of AS 3, and AS 5 is a customer of both AS 3 and AS 4. The relationship between AS 1 and AS 4 can be either customer-to-provider (C2P) or peer-to-peer (P2P). AS 1 advertises prefixes P1 to AS 2 and adds the NO_EXPORT community attribute to the BGP advertisement sent to AS 2, 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. Assuming that AS 1 is the customer of AS 4, if AS 4 deploys EFP-uRPF with algorithm A at customer interfaces, it will require packets with source addresses in P1 or P6 to only arrive from AS 1. When AS 1 sends legitimate packets with source addresses in P1 or P6 to AS 4 through AS 2, AS 4 improperly blocks these packets. The same problem applies to Strict uRPF and FP-uRPF. EFP-uRPF with algorithm B can avoid improper block in this case in principle.

Hidden Prefixes Some servers' source addresses are not advertised through BGP to other ASes. These addresses are unknown to the inter-domain routing system and are called hidden prefixes. Legitimate traffic using these hidden prefixes as source addresses would be dropped by existing inter-domain SAV mechanisms, such as Strict uRPF, FP-uRPF, or EFP-uRPF, because they do not match any known prefix. For example, Content Delivery Networks (CDN) use anycast to improve the quality of service by bringing content closer to users. An anycast IP address is assigned to devices in different locations, and incoming requests are routed to the closest location. Usually, only locations with multiple connectivity announce the anycast IP address through BGP. The CDN server receives requests from users and creates tunnels to the edge locations, where content is sent directly to users using direct server return (DSR). DSR requires servers in the edge locations to use the anycast IP address as the source address in response packets. However, these edge locations do not announce the anycast prefixes through BGP, so an intermediate AS with existing inter-domain SAV mechanisms may improperly block these response packets.

A Direct Server Return (DSR) scenario.

illustrates a DSR scenario where the anycast IP prefix P3 is only 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 4 has deployed inter-domain SAV. When users in AS 2 send requests to the anycast destination IP, the forwarding path is AS 2->AS 4->AS 3. The anycast servers in AS 3 receive the requests and tunnel them to the edge servers in AS 1. Finally, the edge servers send the content to the users with source addresses in prefix P3. The reverse forwarding path is AS 1->AS 4->AS 2. Since AS 4 does not receive routing information for prefix P3 from AS 1, EFP-uRPF with algorithm A/B, and all other existing uRPF-based mechanisms at the customer interface of AS 4 facing AS 1 will improperly block the legitimate response packets from AS 1. Further, in some network scenarios, such as multicast and satellite networks, specific prefixes may be exclusively used as source addresses 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.

Source Address Spoofing within a Customer Cone EFP-uRPF with algorithm B may also permit spoofing traffic improperly in scenarios where source address spoofing within a customer cone occur. We provide illustrations of these scenarios using an example in the following. The source address spoofing within a customer cone represents a class of scenario where spoofing traffic comes from a customer AS within a customer cone and the spoofed source addresses belong to this customer cone. portrays a scenario of source address spoofing within a customer cone and is used to analyze the gaps of uRPF-based mechanisms.

A scenario of source address spoofing within a customer cone.

In , the source address spoofing takes place within AS 4's customer cone, 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 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 with algorithm 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, when the spoofer which is inside of AS 2 or connected to AS 2 through other ASes sends spoofing packets with spoofed source addresses in P5 to AS 3, AS 4 will improperly permit these packets, thus enabling the spoofing traffic to propagate. In scenarios like these, Strict uRPF, FP-uRPF, VRF uRPF, and EFP-uRPF with algorithm A do not suffer from improper permit problems. This is because these mechanisms enforce strict filtering rules that ensure packets with source addresses in P5 are only permitted to arrive at AS 4's customer interfaces facing AS 5.

SAV at Provider/Peer Interfaces SAV is used at provider/peer interfaces to validate traffic entering the customer cone, including both legitimate and spoofing traffic. To prevent packets with spoofed source addresses from the provider/peer AS, ACL-based ingress filtering and/or Loose uRPF can be deployed .

The gaps of ACL-based ingress filtering and Loose uRPF at Provider/Peer Interfaces in the scenarios of interest.

summarizes the gaps of ACL-based ingress filtering and Loose uRPF for SAV at provider/peer interfaces in the corresponding scenarios. ACL-based ingress filtering effectively blocks spoofing traffic from provider/peer AS, while appropriately allowing legitimate traffic. However, these methods may come with 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 the following, we expose the limitations of ACL-based ingress filtering and Loose uRPF for SAV at provider/peer interfaces in scenarios of source address spoofing from provider/peer AS. The source address spoofing from provider/peer AS represents a class of scenario where spoofing traffic comes from a provider/peer AS and the spoofed source addresses belong to the customer cone which the spoofing traffic enters. depicts the scenario of source address spoofing from provider/peer AS and is used to analyze the gaps of ACL-based ingress filtering and Loose uRPF below.

A scenario of source address spoofing from provider/peer AS.

In the case of , 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. The arrows in represent the commercial relationships between ASes. AS 3 acts as the provider or lateral peer of AS 4 and the provider for AS 5, while AS 4 serves 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. By applying ACL-based ingress filtering at the provider/peer interface of AS 4, the ACL rules can block any packets with spoofed source addresses from AS 3 in P1. However, this approach incurs heavy operational overhead, as it requires network operators to update the ACL rules promptly based on changes in prefixes or topology of AS 4's customer cone. Otherwise, it may cause improper block of legitimate traffic or improper permit of spoofing traffic. Loose uRPF can greatly reduce the operational overhead because it uses the local FIB as information source, and can adapt to changes in the network. However, it would improperly permit spoofed packets. In , Loose uRPF is enabled at AS 4's provider/peer interface, while EFP-uRPF is enabled at AS 4's customer interfaces. A spoofer inside AS 3 or connected to it through other ASes may send packets with source addresses spoofing P1 to AS 2. As AS 3 lacks deployment of inter-domain SAV, the spoofing packets will reach AS 4's provider/peer interface. With Loose uRPF, AS 4 cannot block them at its provider/peer interface facing AS 3, and thus resulting in improper permit.

Problem Statement

The scenarios where existing inter-domain SAV mechanisms may have improper block problem for legitimate traffic, improper permit problem for spoofing traffic, or high operational overhead.

Based on the analysis above, we conclude that existing inter-domain SAV mechanisms exhibit limitations in asymmetric routing scenarios, leading to potential issues of improper block or improper permit. Additionally, these mechanisms can result in high operational overhead, especially when network routing undergoes dynamic changes. provides a comprehensive summary of 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. For ACL-based ingress filtering, network operators need to manually update ACL rules to adapt to network changes. Otherwise, they may cause improper block or improper permit issues. Manual updates induce high operational overhead, especially in networks with frequent policy and route changes. Strict uRPF and Loose uRPF are automatic SAV mechanisms, and thus they do not need any manual effort to adapt to network changes. However, they have issues in scenarios with asymmetric routing. Strict uRPF may cause improper block problems when an AS is multi-homed and routes are not symmetrically announced to all its providers. This is because the local FIB may not include the asymmetric routes of the legitimate packets, and Strict uRPF only uses the local FIB to check the source addresses and incoming interfaces of packets. Loose uRPF may cause improper permit problems and fail to prevent source address spoofing. This is because it is oblivious to the incoming interfaces of packets. FP-uRPF improves Strict uRPF in multi-homing scenarios. However, they still have improper block issues in asymmetric routing scenarios. For example, they may not handle the cases of limited propagation of prefixes. These mechanisms use the local RIB to learn the source prefixes and their valid incoming interfaces. But the RIB may not have all the prefixes with limited propagation and their permissible incoming interfaces. EFP-uRPF allows the prefixes from the same customer cone at all customer interfaces. This solves the improper block problems of FP-uRPF in multi-homing scenarios. However, this approach also compromises partial protection against spoofing from the customer cone. EFP-uRPF may still have improper block problems when it does not learn legitimate source prefixes. For example, hidden prefixes are not learned by EFP-uRPF. Finally, existing inter-domain SAV mechanisms cannot work in all directions (i.e., interfaces) of ASes to achieve effective SAV. Network operators need to carefully analyze the network environment and choose appropriate SAV mechanism for each interface. This leads to additional operational and cognitive overhead, which hinders the rate of adoption of inter-domain SAV.

Requirements for New Inter-domain SAV Mechanisms This section lists the requirements which can help bridge the technical gaps of existing inter-domain SAV mechanisms. These requirements serve as the practical guidelines that can be met, in part or in full, by proposing new techniques.

Accurate Validation The new inter-domain SAV mechanism MUST improve the validation accuracy in all directions of ASes over existing inter-domain SAV mechanisms, while working in incremental/partial deployment and providing necessary security guarantee.

Improving Validation Accuracy over Existing Mechanisms The new inter-domain SAV mechanism MUST avoid improper blocking and reject more spoofed traffic than existing inter-domain SAV mechanisms. To achieve this, for an AS performing inter-domain SAV on an interface connected to a neighboring AS, it MUST permit all prefixes whose legitimate traffic (using them as source addresses) can reach that interface, while blocking all other prefixes that cannot. This general principle applies to customer, lateral peer, and provider interfaces. Multiple sources of SAV-related information, such as ROA and ASPA objects, BGP Update data, SAV-specific information, and management information can be leveraged to meet this requirement.

An example where both spoofing and legitimate traffic arrive from the same direction. AS 3->AS 4. The spoofing traffic with SA in P1' arrives at AS 4 along the path AS 2->AS 3->AS 4. ]]>

The path taken by the traffic with spoofed source address (i.e., spoofed traffic) may overlap with a path for the legitimate traffic. Such scenarios could result in improper permit of the spoofed traffic at the AS doing SAV unless an AS located at or prior to the merging point of the overlap is also performing inter-domain SAV. As illustrated in , both spoofed and legitimate traffic traverse the same link between AS 3 and AS 4. In this case, SAV filtering at AS 4's interface facing AS 3 cannot differentiate between the two. The spoofed traffic in such scenarios is incrementally mitigated (i.e., blocked) with the wider deployment of SAV. For example, AS 3 can deploy SAV on its interfaces facing AS 1 and AS 2 to facilitate blocking of the spoofed traffic while admitting and propagating the legitimate traffic.

Working in Incremental/Partial Deployment The new inter-domain SAV mechanism MUST NOT assume pervasive adoption (including the adoption of both SAV and SAV-related information) and SHOULD benefit early adopters by providing effective protection from spoofing of source addresses even when it is partially deployed in the Internet. Not all AS border routers can support the new SAV mechanism at once, due to various constraints such as capabilities, versions, or vendors. The new SAV mechanism SHOULD NOT be less effective than existing mechanisms in its capability of protection from source address spoofing for any type of peering interface (customer, lateral peer, and provider) even under partial deployment.

Providing Necessary Security Guarantee The new inter-domain SAV mechanism SHOULD secure the communicated SAV-related information between ASes. It SHOULD prevent malicious ASes from generating forged information or detect and filter the forged information from malicious ASes.

Automatic Update The new inter-domain SAV mechanism SHOULD update SAV rules and detect the changes of SAV-specific information automatically while guaranteeing convergence.

Reducing Operational Overhead The new inter-domain SAV mechanism MUST be able to adapt to dynamic networks and asymmetric routing scenarios automatically, instead of relying on manual update. At least, it MUST have less operational overhead than ACL-based ingress filtering.

Guaranteeing Convergence The new inter-domain SAV mechanism SHOULD promptly detect the network changes and finish the convergence process quickly. It is essential that the new inter-domain SAV mechanism converges towards accurate SAV rules in a proper manner, effectively reducing improper block and improper permit throughout the whole convergence process.

Inter-domain SAV Scope The new inter-domain SAV mechanisms should work in the same scenarios as existing ones. Generally, it includes all IP-encapsulated scenarios:

• Native IP forwarding: This includes both global routing table forwarding and CE site forwarding of VPN.
• IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): In this scenario, we focus on the validation of the outer layer IP address.
• Both IPv4 and IPv6 addresses.

Scope does not include:

• Non-IP packets: This includes MPLS label-based forwarding and other non-IP-based forwarding.

In addition, the new inter-domain SAV mechanisms should not modify data plane packets. Existing architectures or protocols or mechanisms can be inherited by the new SAV mechanism to achieve better SAV effectiveness.

Security Considerations SAV rules can be generated based on route information (FIB/RIB) or non-route information. If the information is poisoned by attackers, the SAV rules will be false. Legitimate packets may be dropped improperly or malicious traffic with spoofed source addresses may be permitted improperly. Route security should be considered by routing protocols. Non-route information, such as RPKI ASPA objects, should also be protected by corresponding mechanisms or infrastructure. If SAV mechanisms or protocols require exchanging specific information between ASes, some considerations on the avoidance of message alteration or message injection are needed to propose.

IANA Considerations This document does not request any IANA allocations.

Contributors Nan Geng
Huawei
Beijing, China
Email: gengnan@huawei.com

References Normative References 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. 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. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. Informative References Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community. A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community. Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. MANRS Internet Society NIST Cisco Systems, Inc. NIST, Akamai

Acknowledgements Many thanks to Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, John O'Brien, and Roland Dobbins, for their valuable comments on this document. Apologies to any others whose names the authors may have missed mentioning.