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 ). However, previous SAV solutions cannot meet the design goal due to technical limitations (see and ). Existing advanced SAV solutions (e.g., EFP-uRPF and BAR-SAV ) 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. The allowlist must contain all prefixes belonging to the corresponding customer cone. When adopting SAV based on the allowlist, the interface only allows incoming data packets using source addresses that are covered in the allowlist. However, using an allowlist may cause legitimate traffic to be blocked if the allowlist fails to cover all prefixes in the customer cone. This document analyzes potential improper block problems when using the allowlist. To enhance the SAV robustness and avoid improper block, this document provides an additional option for network operators, i.e., generating a blocklist filter by using 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. Network operators can flexibly use the allowlist or blocklist on different interfaces 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 links.

Improper Block When the Allowlist is Incomplete The basic idea of existing advanced 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 in the customer cone and only accepts data packets using source addresses belonging to 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 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 the customer cone of AS4. 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 ASes in the customer cone do not register ASPAs or ROAs, the SAV solution will still fail to discover all prefixes in the customer cone. If the allowlist is not complete, it will improperly block data packets using legitimate source addresses. Overall, considering the complexity of inter-domain routing, existing SAV solutions which solely use allowlist filters may fail to identify all prefixes of the customer cone (e.g., when some prefixes are limited propagated in the customer cone). In this case, the incomplete allowlist will result in improper block.

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 block. Bicone SAV aims to avoid block 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 block.
Maintaining directionality. When using an allowlist, the SAV filter can block data packets using source addresses not belonging to the customer cone of the customer or lateral peer AS. When using a blocklist, the SAV filter can block data packets using source addresses belonging to the provider cone. It cannot prevent an AS in the customer cone of a customer or lateral peer AS from using source addresses of the customer cone of another customer or lateral peer AS. Therefore, the allowlist filter has stricter directionality than the blocklist filter.

Overall, the blocklist performs better in achieving the first goal while the allowlist performs better in achieving the second goal. In the following, this document introduces existing allowlist-based SAV solutions and the design of a new blocklist-based SAV solution.

Allowlist-based SAV Solution Existing SAV solutions (e.g., EFP-uRPF , BAR-SAV ) can be used to generate an allowlist on interfaces facing a customer or lateral peer AS by using BGP updates, ROAs, and ASPAs related to the corresponding customer cone.

Blocklist-based SAV Solution This section introduces a blocklist-based SAV solution that generates blocklist filters on interfaces facing a customer or lateral peer AS 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 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. When using the blocklist on an interface facing a customer or lateral peer AS, data packets received from that interface using source addresses in the blocklist should be blocked.

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 P1.
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.
Form the union of Prefix-set P1 and Prefix-set P2. Apply this union set as a blocklist on an interface facing a customer or lateral peer AS.

Overlap Between Provider Cone and Customer Cone In some scenarios (e.g., the CDN and DSR scenario described in and ), a prefix may exist both in the provider cone and the customer cone. To avoid improper block, the blocklist must remove prefixes that also belong to the customer cone. These prefixes can be identified by computing the overlap between blocklist and allowlist.

Incremental 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 will not include all prefixes in the provider cone. When the blocklist is incomplete, the blocklist will not improperly block legitimate data packets and will still block spoofing data packets using source addresses in the blocklist. It provides immediate incremental benefits to adopters.

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 The primary goal of SAV is to avoid improper block while maintaining directionality. Avoiding improper block is more important because discarding legitimate traffic will cause serious traffic interruption. On the basis of avoiding improper block, 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 block, thus failing to meet the goal. For a blocklist, it will not improperly block legitimate data packets whether the blocklist is complete or not. In terms of improper admit, the blocklist has much less improper admits than loose uRPF and has more improper admits than the allowlist. 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 is 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 challenging. If network operators cannot determine the integrity of the allowlist, the blocklist is recommended to avoid possible improper block.

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.

Summary of 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 has neither improper block nor improper admit. When the customer cone size is relatively small, it would be easier for the network operator to determine whether the allowlist is complete, and the allowlist size should be relatively small as well.
If the network operator cannot determine the integrity of the allowlist, it is recommended to use a blocklist filter to avoid improper block. In addition, given the storage overhead, the blocklist should be more appropriate than the allowlist on interfaces facing a very large customer cone.

For example, in , it is recommended that AS4 uses the blocklist filter at AS4-AS2 interface, since the use of the allowlist filter here may have improper block problems. If AS4 can ensure that the use of allowlist filter at AS4-AS5 interface will not cause improper block, then it is recommended to use allowlist filter at AS4-AS5 interface. In this way, SAV at AS4 can avoid improper block while maintaining directionality. For data packets received from AS5, SAV at AS4 will block data packets using source addresses not belonging to AS1, AS3, and AS5. For data packets received from AS2, SAV at AS4 will block data packets using source addresses belonging to the provider cone of AS4.

Security Considerations The security considerations described in , , , , and also applies to this document. Users should be aware of the potential risks of using ASPAs and ROAs to generate SAV filters, such as misconfiguration and update delay of RPKI repository.

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, and many other members of the SIDROPS and SAVNET working groups for comments and discussion.