Bicone Source Address Validation

Introduction Source address spoofing is one of the most serious security threats to today's Internet. It serves as a main attack vector for large-scale 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 ). Existing advanced SAV solutions (e.g., EFP-uRPF ) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS by using information related to the customer cone of that AS. When adopting SAV based on the allowlist, the interface only allows incoming data packets using source addresses that are covered in the allowlist. Therefore, the allowlist must contain all prefixes belonging to the corresponding customer cone. Otherwise, if the allowlist is incomplete, it will improperly block legitimate traffic from the corresponding customer cone. This document analyzes the potential improper block problems when using an allowlist. To avoid improper blocks, this document proposes a new SAV solution by generating an ingress SAV blocklist filter based on BGP updates, ROAs, and ASPAs related to the provider cone. The blocklist should contain as many prefixes belonging to the provider cone as possible. When adopting SAV based on the blocklist, the interface blocks incoming data packets using source addresses that are covered in the blocklist. In practice, network operators can flexibly decide to use a blocklist or an allowlist according to their requirements and actual conditions. 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 Improper Block: The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV filters. Provider Cone: The set of ASes an AS can reach by using only Customer-to-Provider (C2P) links.

Improper Block When the Allowlist is Incomplete The basic idea of existing allowlist-based SAV solutions is generating an allowlist by using information related to the customer cone of a customer or lateral peer AS. Specifically, they identify prefixes belonging to the corresponding customer cone and only allows data packets using source addresses in these prefixes on the interface facing that customer or lateral peer AS. This is because data packets received from a customer or lateral peer AS should use source addresses belonging to the customer cone of that AS unless there is a route leak . EFP-uRPF (BCP84 ) generates allowlists by using BGP UPDATE messages related to the corresponding customer cone. However, if a multi-homed AS in customer cone limits propagation of its prefixes, EFP-uRPF may miss these prefixes in the allowlist, resulting in improper blocks. 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.

An example of limited propagation of prefixes in the customer cone illustrates a similar scenario of limited propagation of prefixes in the customer cone of AS4. Arrows in the figure indicate propagation direction of BGP announcements as well as AS relationship (i.e., Provider-to-Customer (P2C), Customer-to-Provider (C2P), or Peer-to-Peer (P2P)) from sending AS to receiving AS. AS1 announces the route for prefixes P1 and P2 to its two provider ASes, i.e., AS2 and AS3. Since AS1 attaches NO_EXPORT in the BGP UPDATE message sent to AS2, AS2 will not propagate the route to AS4. As a result, AS4 only receives the route to prefixes P1 and P2 from its lateral peer or provider AS5. If AS4 uses EFP-uRPF (including Algorithm A and Algorithm B) to generate an allowlist on AS4-AS2 interface, the allowlist will not contain prefixes P1 and P2, and thus will improperly block data packets using source addresses in prefixes P1 or P2. More recent SAV solutions (e.g., BAR-SAV ) additionally use Autonomous System Provider Authorization (ASPA) and Route Origin Authorization (ROA) related to the customer cone to generate a more robust allowlist. Since registering ASPAs and ROAs is optional for network operators, ASPAs and ROAs would be partially deployed for a long time. When some ASes in the customer cone (e.g., AS1 in ) do not register ASPAs or ROAs, this kind of solutions will still fail to discover all prefixes belonging to the customer cone, leading to an incomplete allowlist. If the allowlist is incomplete, it will improperly block data packets using legitimate source addresses. Overall, considering the complexity of inter-domain routing, existing SAV solutions which use allowlist filters on interfaces facing a customer or lateral peer AS may fail to identify all prefixes of the corresponding customer cone. In this case, the incomplete allowlist will have improper blocks.

Goals of Bicone SAV Bicone SAV aims to achieve more robust ingress SAV filtering on interfaces facing a customer or lateral peer AS by flexibly using allowlist or blocklist filters. It has two main goals:

Avoiding improper blocks. Bicone SAV aims to avoid blocking legitimate data packets received from a customer or lateral peer AS. As described in , if the allowlist is incomplete, it will improperly block legitimate data packets. In this case, it is recommended to use a blocklist to avoid improper blocks.
Maintaining directionality. Unlike Loose uRPF which completely loses directionality, Bicone SAV aims to identify more source-spoofed data packets by maintaining directionality. In general, the allowlist filter has stricter directionality than the blocklist filter, so using an allowlist will have less improper admits.

Blocklist Generation This section introduces how to generate a blocklist by using BGP updates, ROAs, and ASPAs related to the provider cone.

Key Idea The provider cone of an AS is defined as the set of ASes an AS can reach by using only Customer-to-Provider (C2P) links. Considering prefixes only 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 can contain prefixes only belonging to the provider cone. When using the blocklist on an interface facing a customer or lateral peer AS, it will block data packets received from that interface using any source address in the blocklist.

An example of the multi-homed prefix To generate such a blocklist, an AS can first identify ASes in its provider cone by using ASPAs and AS-PATH in BGP UPDATE messages. Then, it can discover prefixes belonging to these ASes by using ROAs and BGP UPDATE messages. Subsequently, it must remove prefixes that also belong to its customer cone. For example, in , both AS1 and AS6 announce the route for prefix P1. If the blocklist on AS4-AS2 interface contains Prefix P1, it will cause improper blocks. Since an AS may not know if a prefix is belonging to its customer cone (as analyzed in ), it should remove all suspicious prefixes. To this end, it can use all BGP UPDATE messages and ROAs to identify prefixes that are belonging to both ASes in the provider cone and ASes not in the provider cone. These prefixes should not be contained in the blocklist to avoid any potential improper block. Finally, it can include the remaining prefixes in the blocklist.

Generation Procedure A detailed description of blocklist generation procedure is as follows:

Create the set of all directly connected Provider ASNs. Call it AS-set Z(1).
Create the set of all unique AS_PATHs in Adj-RIBs-In of all interfaces facing Providers.
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.
Let i = N
Decrement i to i-1.
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.
If i == 1, go to Step 3. Else, go to Step 5.
Let k = 1.
Increment k to k+1.
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).
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.
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 S1.
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 S2.
Form the union of Prefix-set S1 and Prefix-set S2 as Prefix-set S3.
For each unique Prefix P in Prefix-set S3, check origin ASNs of Prefix P and its sub prefixes by using all ROAs and in Adj-RIBs-In of all interfaces. If all unique Prefixes in Prefix-set S3 have been processed, go to Step 17.
For each prefix of Prefix P and its sub prefixes, if the prefix has at least one origin ASN not in AS-set Z(k_max), remove the prefix from Prefix-set S3. Go to Step 15.
Apply Prefix-set S3 as a blocklist on interfaces facing a customer or lateral peer AS.

By following the above procedure, AS4 in and can generate a blocklist on AS4-AS2 interface. The blocklist contains prefixes that belong only to the provider cone of AS4 and does not contain prefixes P1 and P2. If AS4 uses this blocklist SAV filter on the interface facing AS2, it will not improperly block data packets using source addresses in prefixes P1 and P2. Meanwhile, it can accurately identify and block source-spoofed data packets using source addresses in the blocklist. Therefore, this blocklist SAV filter can address the improper block problems of existing allowlist SAV filters, while maintaining directionality.

Incremental and Partial Deployment of ASPAs Note that it is difficult for an AS to identify all ASes in its provider cone when some ASes in the provider cone do not register ASPAs. Therefore, the generated blocklist may not include all prefixes in the provider cone under incremental and partial deployment of ASPAs. The main advantage of blocklist over allowlist is that, when the blocklist is incomplete, the blocklist will not improperly block legitimate data packets and will still block source-spoofed data packets using source addresses in the blocklist, providing immediate incremental benefits to adopters.

A Challenging Scenario The Content Delivery Networks (CDN) and Direct Server Return (DSR) scenario is a challenging scenario for both allowlist-based SAV and blocklist-based SAV. In , AS6 announces the route for anycast prefix P3. However, although AS1 does not announce the route for prefix P3 or register a ROA for prefix P3, it will send data packets using source addresses in prefix P3 due to the DSR technology. If AS4 applies an allowlist on interface AS4-AS2, the allowlist will not contain prefix P3. If AS4 applies a blocklist on interface AS4-AS2, the blocklist will contain prefix P3. Therefore, both allowlist and blocklist on interface AS4-AS2 will improperly block data packets using source addresses in prefix P3. One possible solution is that the network operator manually identifies the special purpose prefixes for anycast and DSR, and either removes them from the blocklist or adds them to the allowlist.

An example of the CDN and DSR scenario

Implementation and Operations Considerations Network operators are advised to flexibly use either allowlist or blocklist on interfaces facing different customer or lateral peer ASes according to their requirements and actual conditions.

Meeting the Goals Avoiding improper blocks is more important because discarding legitimate traffic will cause serious traffic interruption. On the basis of avoiding improper blocks, the less improper admits of SAV, the better. If the allowlist on an interface is complete, it will have no improper block and no improper admit. But if the allowlist is incomplete due to hidden prefixes (e.g., prefixes P1 and P2 in ) in the customer cone and lack of necessary ASPAs, the allowlist will have improper blocks, thus failing to meet the goal. For a blocklist, it will not improperly block legitimate data packets whether the blocklist is complete or not. Therefore, if the allowlist on an interface is complete, network operators are advised to use the allowlist. Otherwise, network operators are advised to use the blocklist. For small ISPs with a smaller customer cone size, it is easier to determine whether an allowlist is complete because there are fewer ASes in the customer cone and the routing should be relative simple. For example, they can ask a customer or lateral peer AS whether all ASes in its customer cone have deployed ASPAs. But for large ISPs with a larger customer cone size, it is more challenging. If network operators cannot determine the integrity of the allowlist, the blocklist is recommended to avoid possible improper blocks.

Storage Overhead Additional memory (i.e., ternary content-addressable memory (TCAM)) is required to store the allowlist or blocklist in line cards. Network operators need to take storage overhead into consideration when deploying allowlists or blocklists. Generally, a small ISP will generate a smaller allowlist and a larger blocklist, while a large ISP will generate a larger allowlist and a smaller blocklist. A possible way to save memory is to store the original list in the control plane, with only the aggregated list stored in memory. For example, if the original list contains prefixes P1 and P2 and prefix P1 is a less-specific prefix of prefix P2, then only prefix P1 is stored in memory.

Implementation and Operations Recommendations For an interface facing a customer or lateral peer AS:

If the network operator can determine that the allowlist covers all prefixes of the facing customer cone, it is recommended to use an allowlist on the interface because the complete allowlist would have neither improper blocks nor improper admits.
If the network operator cannot determine the integrity of the allowlist, it is recommended to use a blocklist filter to avoid improper blocks. It is highly recommended to use Loose uRPF and the blocklist together to block more spoofing data packets than solely using Loose uRPF or the blocklist. Loose uRPF is used to block data packets using unallocated or unrouteable source addresses. The blocklist is used to block data packets using source addresses that only belong to the provider cone.

Network operators are allowed to manually modify or configure the allowlist or the blocklist according to their local knowledge. For example, to improve the use of blocklist, they can add special purpose prefixes that will not be used as source addresses of data packets or remove prefixes that would be used for anycast and DSR. This operation can also be achieved automatically if there is a public prefix list that contains the required prefixes, e.g., IANA IPv4 Special-Purpose Address Registry .

Security Considerations The security considerations described in , , , , and also applies to this document.

IANA Considerations This document has no IANA requirements.

Acknowledgements The authors would like to thank Ben Maddison, Kotikalapudi Sriram, Nan Geng, Aijun Wang, Shengnan Yue, Siyuan Teng, Igor Lubashev, Job Snijders, and many other members of the SIDROPS and SAVNET working groups for comments and discussion.