]> Bicone Source Address Validation Tsinghua University
Beijing China tolidan@tsinghua.edu.cn
Tsinghua University
Beijing China qlc19@mails.tsinghua.edu.cn
Zhongguancun Laboratory
Beijing China lichen@zgclab.edu.cn
Zhongguancun Laboratory
Beijing China liulb@zgclab.edu.cn
Operations and Management SIDROPS SAV The primary design goal of source address validation (SAV) is avoiding improper block (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see and ). Existing advanced SAV solutions typically generate ingress SAV allowlist filters by using information related to customer cone. This document analyzes potential improper block problems of solely using allowlist filters. To minimize improper block, this document proposes Bicone SAV, which enhances the SAV technology by additionally using blocklist filters generated based on information related to provider cone.
Introduction Source address spoofing is one of the most serious security threats to today's Internet. It serves as a main attack vector for Distributed Denial of Service (DDoS) attacks and is commonly used in reflective DDoS attacks. To mitigate source address spoofing, many source address validation (SAV) solutions (e.g., BCP38 and BCP84 ) have been proposed. The primary design goal of SAV solutions is avoiding improper block (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see and ). However, previous SAV solutions cannot meet the design goal due to technical limitations (see and ). Existing advanced SAV solutions (e.g., EFP-uRPF ) typically generate ingress SAV allowlist filters by using information related to customer cone. Specifically, they aim to generate an allowlist on an interface facing a customer or lateral peer AS by identifying prefixes in the customer's or lateral peer AS's customer cone. However, solely using an allowlist may cause legitimate traffic to be blocked if the allowlist fails to cover all prefixes in a customer cone. This document analyzes potential improper block problems of solely using allowlist filters, and proposes Bicone SAV to minimize improper block. Bicone SAV focuses on generating robust ingress SAV filters for an interface facing a customer or lateral peer AS. In addition to applying an allowlist like existing advanced SAV solutions, Bicone SAV applies a blocklist generated by identifying prefixes in the provider cone. The reader is encouraged to be familiar with , , , and .
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 Provider cone: the set of ASes an AS can reach by using only customer-to-provider links.
Improper Block Problems of Solely Using An Allowlist The basic idea of existing advanced SAV solutions is generating an allowlist by using information related to a customer's (or lateral peer's) customer cone. Specifically, they identify prefixes in a customer's (or lateral peer's) customer cone and only accepts data packets with source addresses belonging to these prefixes on the interface facing that customer (or lateral peer). This is because data packets received from a customer or lateral peer should use source addresses belonging to prefixes in the customer's or lateral peer's customer cone unless there is a route leak . EFP-uRPF (BCP84 ) generates allowlists by using BGP UPDATE messages related to the customer cone. However, if a multi-homed AS in the customer cone limits the propagation of its prefixes, EFP-uRPF may miss these prefixes in the allowlist, resulting in improper block. Section 3.3 of has given such an example of limited propagation of prefixes where a multi-homed customer AS attaches NO_EXPORT to all prefixes announced to one transit provider. illustrates a similar scenario of limited propagation of prefixes in customer cone. Since AS1 attaches NO_EXPORT to routes for P1 and P2 announced to AS2, routes for P1 and P2 are not propagated on the AS2-AS4 interface. Because AS4 never receives routes for P1 and P2 from its customer AS2, both EFP-uRPF Algorithm A and Algorithm B at AS4 will block legitimate data packets received on AS4-AS2 interface with source addresses in P1 or P2.
An example of limited propagation of prefixes in the customer cone
Some more recent SAV solutions (e.g., BAR-SAV ) additionally use Autonomous System Provider Authorization (ASPA) and Route Origin Authorization (ROA) to generate a more robust allowlist. However, since registering ASPAs and ROAs is optional for network operators, ASPAs and ROAs will be partially deployed for a long time. When some ASPAs and ROAs are missing, the SAV solution will still fail to discover all prefixes in a customer's or lateral peer's customer cone, leading to improper block. Overall, considering the complexity of inter-domain routing, existing SAV solutions which solely use an allowlist may fail to identify all prefixes in a customer's (or lateral peer's) customer cone. In this case, the generated allowlist may result in improper block. To minimize improper block, Bicone SAV additionally generates a blocklist on an interface facing a customer or lateral peer by using BGP UPDATE messages, ASPAs, and ROAs that are related to the provider cone. In the following, describes how to generate the blocklist and describes how to perform more robust ingress SAV filtering by using both allowlist and blocklist filters.
Generating A Blocklist Using Information Related to Provider Cone Bicone SAV enhances the robustness of SAV through using a blocklist on an interface facing a customer or lateral peer. The provider cone of an AS is defined as the set of ASes an AS can reach by using only customer-to-provider links. Considering prefixes associated with ASes in the provider cone should not be used as source addresses in data packets received from any customer or lateral peer AS unless there is a route leak . The blocklist should contain prefixes belonging to the provider cone. To generate a blocklist, an AS first identifies ASes in its provider cone by using ASPAs and AS-PATH in BGP UPDATE messages. Then, it discovers prefixes belonging to these ASes in provider cone and includes those prefixes in the blocklist. Data packets received from customers or lateral peers with source addresses in the blocklist should be blocked. Note that if an AS cannot identify all ASes in the provider cone when ASPAs are partially deployed, the generated blocklist will not include all prefixes in the provider cone. In this case, the generated blocklist can still block spoofing traffic received from customers and lateral peers with source addresses in the blocklist. Therefore, Bicone SAV provides immediate incremental benefits to early adopters. A detailed description of blocklist generation procedure is as follows:
  1. Create the set of all directly connected Provider ASNs. Call it AS-set Z(1).
  2. Create the set of all unique AS_PATHs in Adj-RIBs-In of all interfaces facing Providers.
  3. For each unique AS_PATH with N (N>1) ASNs, i.e., [ASN_{1}, ASN_{2}, ..., ASN_{i}, ASN_{i+1}, ..., ASN_{N}] where ASN_{i} is the ith ASN in AS_PATH and the first ASN (i.e., ASN_{1}) is a directly connected Provider ASN. If all unique AS_PATHs have been processed, go to Step 8.
  4. Let i = N
  5. Decrement i to i-1.
  6. If ASN_{i} authorizes ASN_{i+1} as a Provider in ASN_{i}'s ASPA, ASNs from ASN_{1} to ASN_{i+1} (i.e., ASN_{1}, ASN_{2}, ..., ASN_{i}, and ASN_{i+1}) are included in AS-set Z(1) and go to Step 3.
  7. If i == 1, go to Step 3. Else, go to Step 5.
  8. Let k = 1.
  9. Increment k to k+1.
  10. Create AS-set Z(k) of ASNs that are not in AS-set Z(k-1) but are authorized as Providers in ASPAs of any ASN in AS-set Z(k-1).
  11. If AS-set Z(k) is null, then set k_max = k-1 and go to Step 12. Else, form the union of AS-set Z(k) and AS-set Z(k-1) as AS-set Z(k) and go to Step 9.
  12. Select all ROAs in which the authorized origin ASN is in AS-set Z(k_max). Form the union of the sets of prefixes in the selected ROAs. Call it Prefix-set P1.
  13. Using the routes in Adj-RIBs-In of all interfaces facing Providers, create a set of prefixes originated by any ASN in AS-set Z(k_max). Call it Prefix-set P2.
  14. Form the union of Prefix-set P1 and Prefix-set P2. Apply this union set as a blocklist on every interface facing a Customer or Lateral Peer.
Using Both Allowlist and Blocklist Filters Although using a blocklist helps reduce improper block when an allowlist does not include all prefixes in a customer's or lateral peer's customer cone, it may also block legitimate traffic in the CDN and DSR scenario as existing SAV solutions do (see and ). To minimize improper block, it is recommended to use both allowlist and blocklist filters. The allowlist is generated by discovering as many prefixes in the customer's or lateral peer's customer cone as possible (see and ) and the blocklist is generated by discovering as many prefixes in the provider cone as possible (see ). A detailed description of SAV procedure is as follows:
  1. Check if source addresses of data packets received from a customer or lateral peer are included in the corresponding allowlist. If so, these data packets are accepted. If not, go to Step 2.
  2. Check if source addresses of data packets received from a customer or lateral peer are included in the corresponding blocklist. If so, these data packets are blocked. If not, these data packets should be accepted to avoid improper block.
If an AS can make sure the generated allowlist covers all prefixes in a customer's or lateral peer's customer cone, it does not need to use a blocklist on that corresponding interface and can only accept data packets received on that interface with source addresses in the allowlist.
Security Considerations The security considerations described in , , , , and also applies to this document.
IANA Considerations This document has no IANA requirements.
References Normative References Enhanced Feasible-Path Unicast Reverse Path Forwarding 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. A Profile for Autonomous System Provider Authorization Yandex JetLend Internet Initiative Japan Fastly Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. A Profile for Route Origin Authorizations (ROAs) This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK] BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects Yandex Qrator Labs Internet Initiative Japan & Arrcus, Inc. Arrcus Fastly 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 type of AS_PATH verification provides detection and mitigation of route leaks and improbable AS paths. It also provides protection, to some degree, against prefix hijacks with forged-origin or forged-path-segment. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing 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. Ingress Filtering for Multihomed Networks 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. Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements Tsinghua University Tsinghua University Tsinghua University Huawei Huawei This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) USA National Institute of Standards and Technology Akamai Technologies USA National Institute of Standards and Technology Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. Problem Definition and Classification of BGP Route Leaks 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.