]> 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 huangmq@vip.sina.com

USA National Institute of Standards and Technology

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

Routing SAVNET This document analyzes the problem space and provides a gap analysis of existing inter-domain source address validation (SAV) mechanisms. Based on these findings, it outlines the technical requirements for future improvements.

Introduction Source Address Validation (SAV) is a fundamental mechanism for detecting and mitigating source address spoofing attacks . Inter-domain SAV, defined in the context of Internet routing using BGP-4 , checks the source addresses of data traffic received from a neighboring Autonomous System (AS), whether that traffic originated within the neighbor's network or is being transited through it. Inter-domain SAV is applied at border routers to incoming traffic on external interfaces directly connected to a neighboring AS. The local AS (SAV-performing AS) and the neighbor AS are connected using external BGP (eBGP). The neighbor AS could be using either a public AS number (ASN) or a private ASN . This document analyzes the problem space and provides a gap analysis of existing inter-domain SAV mechanisms. Based on these findings, it outlines the technical requirements for future improvements. The corresponding work related to intra-domain SAV is documented in , which includes SAV for hosts and customers (non-AS) connected to the AS . The progression of inter-domain SAV solutions—from the Strict, Feasible-Path, and Loose unicast Reverse Path Forwarding (uRPF) variants in to the Enhanced Feasible-Path uRPF in —demonstrates an ongoing effort to improve validation efficacy based on three primary criteria. These criteria are: (1) avoiding improper blocking due to asymmetric routing, (2) avoiding improper blocking of hidden prefixes and limited propagation prefixes (see Section 4), and (3) enforcing directionality to reduce improper permits by rejecting prefixes that do not legitimately originate from the customer cone of the relevant interface. (A comprehensive list of requirements is in .) Future SAV solutions must be designed to fully satisfy the first two criteria—eliminating false positives—provided their mechanisms are implemented by both the SAV-performing AS and the potential victim AS (and the prefix owners present there). In contrast, satisfying the third criterion requires broader participation. It can be incrementally achieved throughout a customer cone associated with an interface of interest as more intermediate ASes adopt the solution. Consequently, unless there is full SAV deployment within a given customer cone, improper permits are not fully preventable for spoofed traffic originating from within that same customer cone (see ). The eBGP sessions between the border routers of the SAV-performing AS and the neighbor ASes may include Customer-to-Provider (C2P), Provider-to-Customer (P2C), lateral peering (P2P), and Route Server (RS) to RS-client connection. 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 RS and RS-client. As described in , a route server exchanges BGP routes among its clients without forwarding their data traffic. The traffic an RS-client receives at an IXP comes from the member ASes, often over one interface shared by route-server and bilateral peers. For the purposes of SAV, that interface may be treated (1) like a provider interface for simplicity (compromise of directionality), or (2) like a union of lateral peers considering all the ASes the RS-client exchanges routes with at the IXP (reduced compromise of directionality). For the terminology used in this section and the rest of the document, see . 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 and BCP 84 ) are considered for the gap analysis. This document analyzes the technical gaps of existing inter-domain SAV mechanisms in and summarizes them in . Based on this analysis, identifies the requirements for new inter-domain SAV mechanisms to address these gaps. 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, SAV mechanisms based on data packet modification are outside the scope of this document.

Terminology

SAV table:

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 table'.

Improper Block:

The validation results in packets with legitimate source addresses being blocked improperly due to an inaccurate SAV table. (The terms 'improper block' and 'false positive' are used synonymously.)

Improper Permit:

The validation results in packets with spoofed source addresses being permitted improperly due to an inaccurate SAV table. (The terms 'improper permit' and 'false negative' are used synonymously.)

Customer Cone:

The Customer Cone (CC) 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.

Prefixes in the CC:

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.

SAV-related Information:

Routing information (e.g., RIBs and FIBs populated by routing protocols or by the local configuration information -- described below -- provided by the AS operator) 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.

SAV-specific Information:

Information dedicated to SAV, which may be defined and exchanged between ASes using 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). It may also come from the local configuration information provided by the AS operator.

Configuration Information:

This information is configured locally by the AS operator. For example, an AS provisions (suballocates) prefixes p1 and p2 for a non-BGP customer network, which also owns an RIR-allocated prefix p3. The customer instructs the AS to advertise p1 via eBGP on the public Internet, restrict p2 strictly to internal use (in the customer network), and refrain from advertising p3 while still allowing it to source outbound traffic. The AS locally configures these prefixes accordingly. This configuration information is valuable for both intra-domain SAV to permit expected prefixes and inter-domain SAV at other interfaces to block unexpected prefixes. Configuration that populates the RIB or FIB (e.g., static routes) is SAV-related information; configuration made for SAV (e.g., p3 above) is SAV-specific information.

Direct Server Return (DSR):

A traffic delivery model commonly used by Content Delivery Networks (CDNs) that use anycast service addresses while delivering data from edge locations that do not announce those addresses. In such deployments, a request is received by the anycast server, but the response is sent directly by another server (i.e., the edge server) with the anycast service address as the source address, rather than the address used to reach the edge server. This can create a legitimate hidden-prefix scenario.

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. The ACL rules may be generated based on local configuration information (), possibly combined with other sources. However, ACL-based ingress SAV filtering, when not automated, 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 (perhaps erroneously) as a denylist on a provider interface to block source prefixes that are clearly invalid in the inter-domain routing context, such as internal-use-only prefixes of the SAV-performing AS, IANA special purpose prefixes, and unallocated IPv4/IPv6 prefixes. But it is impractical to store and maintain a very large and dynamically varying set of unallocated IPv6 prefixes. Instead, it may be more practical, for example, to compute an ACL denylist containing the internal-use-only prefixes and prefixes originated exclusively by the SAV-performing AS and subtract the denylist from a SAV table computed by a uRPF method. Also, for the interfaces with a customer AS, the ACL-only method is impractical while other techniques (using uRPF as described below) are more effective. ACL-based ingress SAV filtering (ACL allowlist) has applicability in scenarios such as (1) directly connected subnets with hosts, or (2) broadband cable, fiber-optic cable, or digital subscriber access loop (DSL) access networks. In these cases, where the service provider should have a clear knowledge of IP address prefixes provisioned (and configured) to manage those services, the ACL-only method in an allowlist form is applicable.
• 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 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. These modes are briefly described as follows:
  • Strict uRPF : 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 .
  • Loose uRPF : 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 IPv6 addresses, multicast addresses, etc.). If the FIB contains a default route, Loose uRPF permits packets with any source address, unless the implementation excludes the default route from the check or applies additional interface-based checks (, Sections and ).
  • Feasible Path uRPF (FP-uRPF) : 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 ), even if the route is not 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 did not take the "best" path back to the sender.
  • Enhanced Feasible Path uRPF with Algorithm A (EFP-uRPF Alg-A) : 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 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) : 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 (SAV table) 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 : VRF uRPF uses a separate VRF table for each external BGP peer and is only a way of implementation for a SAV table.

Note: , augments EFP-uRPF with ROA and reliable Internet Routing Registry (IRR) data. See more about this in , , and .

Gap Analysis The inadequacies of inter-domain SAV mechanisms can be characterized along three dimensions: improper block (false positives), improper permit (false negatives), and operational overhead. An ideal inter-domain SAV mechanism must block all spoofed traffic while permitting legitimate traffic in all scenarios of interest. However, in some cases, existing SAV mechanisms may unintentionally block legitimate traffic or permit spoofed 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.

SAV at Customer Interfaces 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 (LPP) and Hidden Prefix (HP). They may also cause improper permit in the scenarios of source address spoofing within a CC. One example of LPP scenarios is when an AS attaches NO_EXPORT BGP Community to some prefixes (routes) forwarded to some upstream providers (in multi-homing scenarios) (see ). 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 ). 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 (). 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 case of source address spoofing within a CC. 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 scenarios of Limited Propagation of a Prefix, Hidden Prefix, and source address spoofing within a CC. Illustrations and analyses of these gaps are provided in , , and , respectively.

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

Limited Propagation of a Prefix Scenario In inter-domain networks, some prefixes may not propagate from a customer to all its 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 Strict uRPF, FP-uRPF, and EFP-uRPF Alg-A; the following analysis uses EFP-uRPF Alg-A.

Limited propagation of a prefix caused by NO_EXPORT.

In the scenario of , 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 prefix 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 expect packets with source addresses in P1 or P6 to legitimately arrive only 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. This improper blocking by EFP-uRPF Alg-A persists even when its RPF lists are augmented with ROA or reliable IRR data as described in . Although such data may associate P1 or P6 with AS 1, AS 4 does not receive any BGP route with Origin AS 1 on its customer interface facing AS 2 (). Therefore, the augmentation does not add these prefixes to the RPF list for that interface. EFP-uRPF Alg-B, which recommends for customer interfaces, avoids the improper block in this scenario even without ROA/IRR augmentation because AS 1, the origin AS of those prefixes, is seen on another customer interface of AS 4. However, this comes at the cost of directionality (). Further, Alg-B (even when augmented with ROA or IRR) may still cause improper blocking when the origin AS of the prefix is not seen on any customer interface of the validating AS.

Hidden Prefix Scenario CDNs use the concepts of anycast 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 anycast server 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 servers, from where content is sent directly to users. DSR requires edge servers 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. 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. Suppose AS 1, AS 2, and AS 3 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 P7. The forwarding path for the content packets is AS 1->AS 2. Since AS 2 learns the route for P7 from AS 4 rather than AS 1, Strict uRPF and FP-uRPF at the customer interface of AS 2 facing AS 1 will improperly block these legitimate response packets. EFP-uRPF Alg-A and Alg-B also encounter improper blocking in this scenario, even when the ROA or IRR augmentation described in , is applied. Specifically, P7 is originated by AS 3, while AS 2 does not receive any route with Origin AS 3 from its customer interfaces. Therefore, ROA or IRR data associating P7 with AS 3 would not cause P7 to be added to the RPF list for the customer interface facing AS 1. In contrast, Loose uRPF at AS 2 would permit the response packets, since P7 is present in its FIB and Loose uRPF does not require the incoming interface to match the reverse path. However, this flexibility comes at the expense of directionality in SAV.

A Direct Server Return (DSR) scenario.

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.

Source Address Spoofing within a Customer Cone Scenario 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 table (allowlist) of AS 4 with any SAV mechanism. Assume AS 3 does not enforce 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 a 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 while using EFP-uRPF Alg-B method on customer interfaces. This scenario is not source address spoofing within a CC from the perspective of an individual customer interface of AS 4, but it is source address spoofing within a CC from the perspective of AS 4 looking across all its customer interfaces. 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 table across all customer interfaces.

A scenario of source address spoofing within a customer cone.

In , 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 packets 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 4 and AS 5 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 , 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 a stronger directionality property than EFP-uRPF Alg-B.

SAV at Peer Interfaces 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 customer interfaces may also be used on peer interfaces, 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 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 (). In that case, the gap analysis of would also be applicable to the SAV for peer interfaces.

SAV at Provider Interfaces SAV is used at provider interfaces for validating the traffic entering the AS and destined for the AS's customer cone. 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 spoofed traffic from a 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 spoofed traffic to pass through. In , spoofing from providers refers to a scenario in which spoofed traffic comes from provider ASes, either because they originated it or because they forwarded the spoofed traffic that propagated from their neighbor ASes. 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).

The gaps of ACL-based ingress filtering and Loose uRPF at provider interfaces in the scenarios of interest.

illustrates a scenario of spoofing from providers and is used to analyze the gaps of ACL-based ingress filtering and Loose uRPF.

A scenario of source address spoofing from provider AS.

In , 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 spoofed 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 1 and AS 4 have deployed inter-domain SAV, while the other ASes have not. Using an ACL-only method in the form of a denylist at the provider interface of AS 4 (facing AS 3) is impractical (incurs a very high operational overhead) as mentioned in . 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 (). This is an expected limitation of Loose uRPF.

Gap Analysis Summary provides a comprehensive summary of the gap analyses presented above. It highlights the scenarios where existing inter-domain SAV mechanisms may encounter issues, including instances of improper blocking of legitimate traffic, improper permitting of spoofed traffic, or high operational overhead. The various entries in the table in can be traced back to the terminology and analyses presented in .

Summary of the gap analyses of existing inter-domain SAV mechanisms.

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: Strict uRPF, FP-uRPF, and EFP-uRPF (EFP-uRPF Alg-B less so) 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 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, when not automated, 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 arise from their reliance on BGP data. Although () augments EFP-uRPF with ROA and reliable IRR data, this augmentation still requires the corresponding origin AS to be observed in BGP routes received on the relevant customer interface (Alg-A) or any customer interface (Alg-B). Consequently, improper blocking may persist in certain LPP and HP scenarios. With the availability of authoritative SAV-related information, plus the potential for SAV-specific information (), it would be possible to develop comprehensive new SAV algorithms or mechanisms to overcome the existing gaps.

Requirements for New Inter-domain SAV Mechanisms This section outlines the technical and operational requirements for new inter-domain SAV mechanisms, including considerations for their deployment and operation.

Accurate Validation Any new inter-domain SAV mechanism must provide improved SAV accuracy in terms of improper block and improper permit over existing mechanisms. It must achieve zero improper blocking (i.e., avoid false positives) in the Limited Propagation of a Prefix and Hidden Prefix scenarios (), after the SAV table has converged, provided that the information it relies on is available. Further, it must improve the directionality of filtering (i.e., achieve greater rejection of spoofed traffic) over existing mechanisms. The requirement applies for all directions of AS peering (customer, provider, and peer).

Reducing Operational Overhead Any new inter-domain SAV mechanism should be able to automatically detect changes in the SAV-related information () and/or SAV-specific information () required for generating the SAV table, obtain the updated information, and use the updated information to generate the SAV table.

Early Adopters Benefit in Incremental/Partial Deployment Any new inter-domain SAV mechanism 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. When a proposed solution is implemented by a SAV-performing AS and a potential victim AS (including its prefix owners) within the SAV-performing AS's customer cone, both parties must immediately benefit from the elimination of improper blocking.
Where the SAV-related or SAV-specific information a new mechanism relies on is absent for a prefix or an AS, the mechanism should not improperly block more traffic than the existing mechanism it replaces (e.g., EFP-uRPF Alg-A on customer interfaces); EFP-uRPF Alg-B is not a benchmark here because of its significant compromise of directionality).

Providing Necessary Security Guarantee SAV-related information, e.g., routing information and the existing RPKI signed 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 new inter-domain SAV mechanism introduces or uses SAV-specific information, security mechanisms must exist to prevent malicious injection or alteration of the SAV-specific information. Such mechanisms should also bound the freshness of SAV-specific information.

Efficient Convergence Any new inter-domain SAV mechanism should achieve efficient convergence of the SAV table after any relevant changes occur in the SAV-related information or SAV-specific information used by the mechanism. In this context, convergence refers to the stabilization of the SAV tables on the AS-to-AS interfaces performing SAV. It is essential that any new SAV mechanism properly converges to an updated SAV table, avoiding improper blocking and minimizing improper permits during the transition.

• Additional considerations: Any new SAV proposal should keep the following guidelines in consideration. The initial SAV table computation (prior to SAV enforcement installation) must be performed only when the data used in the computation (e.g., routing tables, RPKI data) are in a stable (i.e., non-transient) state from the local AS's perspective. For instance, if an ASBR in the SAV-performing AS is newly deployed or restarted, then sufficient time must be allowed for routing state convergence to complete before the initial SAV table computation is performed. A similar statement applies for the ASBR with regard to RPKI data convergence. After SAV enforcement installation, the SAV table should be dynamically and quickly updated when new prefixes are discovered (e.g., from BGP Updates or RPKI data updates) for inclusion in the table. However, for removing a prefix from the SAV table (e.g., due to route withdrawal or RPKI changes), applying hysteresis () should be considered in the SAV design.

Troubleshooting Guidance Any new inter-domain SAV solution document should incorporate troubleshooting guidelines within its operational considerations section, following the guidance in . Because an ASBR enforces SAV based strictly on a statically or dynamically computed SAV table, it cannot inherently detect its own validation errors, such as false positives (improper blocks) or false negatives (improper permits). Consequently, a new mechanism should provide (1) counters of packets dropped by SAV per interface, (2) a means to log all or samples of dropped packets, (3) a monitoring-only mode that logs without dropping, and (4) a way to inspect the computed SAV table, including where each entry came from (e.g., BGP, RPKI, local configuration, and SAV-specific information). With the help of these measures, operators can detect and investigate improper blocking before (or in response to) complaints from affected parties.

Deployment Considerations for Private ASes Private ASes were mentioned in . A public AS may serve as a transit gateway for a routing zone utilizing private ASes. These private AS numbers are not visible in external eBGP advertisements because the transit public AS strips them from the AS_PATH using standard vendor features, such as remove-private-as or remove-private . A routing zone or network utilizing only private ASes can still adopt any new inter-domain SAV solutions developed for the public Internet. Implementing these solutions in such environments requires suitable operational modifications, such as employing SLURM (Simplified Local Internet Number Resource Management with the RPKI) to add local ROA prefix assertions for private ASes. Any new inter-domain SAV solution document should incorporate recommendations for suitable operational modifications for this scenario, as necessary.

Security Considerations The SAV table will be generated based on SAV-related information and/or SAV-specific information. If such information is poisoned by attackers, or if stale or replayed SAV-specific information is used, the resulting SAV table will be inaccurate. Consequently, legitimate traffic may be dropped improperly, or spoofed traffic may be permitted improperly. In particular, an attacker able to influence the information used by another AS for SAV table generation may cause improper blocking of legitimate traffic, resulting in denial of service. SAV-specific information may disclose prefixes, routing policy, or business relationships that an AS deliberately keeps out of BGP. For SAV mechanisms that use BGP data as input for generating SAV tables, the use of applicable BGP routing security methods is important. Relevant BGP security methods include route origin validation , route leak prevention , and BGPsec .

IANA Considerations This document does not request any IANA allocations.

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

References Normative References 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 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] 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. Informative References This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK] 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. This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document. 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. This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. 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] 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. The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers. 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] This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted. Zhongguancun Laboratory Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Source address validation (SAV) is an important means to mitigate IP source address spoofing [RFC2827]. This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide. Everything OPS & Arrcus Cisco Old Dog Consulting Nokia Blue Fern Consulting ZTE New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. Yandex Qrator Labs Internet Initiative Japan & Arrcus, Inc. Arrcus BSD Software Development USA National Institute of Standards and Technology This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. Cisco publication Juniper publication MANRS publication Internet Society publication NIST NIST Cisco Systems, Inc. ISC

Acknowledgements 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, Xueyan Song, and Jianping Wu for their reviews, comments, and suggestions. The authors also thank the IESG for their reviews and comments, which helped improve the clarity of this document. Apologies to any others whose names the authors may have inadvertently missed mentioning.