Bicone Source Address Validation

Introduction Source address spoofing remains one of the most serious security threats to today’s Internet. It is a primary attack vector for large-scale Distributed Denial-of-Service (DDoS) attacks and is widely used in reflective DDoS scenarios. To mitigate source address spoofing, a number of Source Address Validation (SAV) solutions have been proposed, including BCP38 and BCP84 . A fundamental design objective of SAV mechanisms is to minimize improper blocking, that is, blocking legitimate traffic, while preserving directionality, as discussed in and . Existing advanced SAV mechanisms, such as EFP-uRPF and BAR-SAV , typically construct ingress SAV allowlist filters on interfaces facing customer or lateral peer Autonomous Systems (ASes). These allowlists are generated using information related to the customer cone of the validating AS. Under an allowlist-based approach, an interface permits incoming data packets only if their source addresses are covered by the allowlist. Consequently, the allowlist is required to include all prefixes belonging to the corresponding customer cone. If the allowlist is incomplete, legitimate traffic from the customer cone may be improperly blocked. To address this limitation, this document explores an alternative SAV approach based on constructing ingress SAV blocklist filters. The proposed blocklist contains prefixes that exclusively belong to the provider cone, referred to as provider-cone-use-only prefixes. Unlike an allowlist, the blocklist is not required to be complete. Instead, it aims to include as many prefixes that can be confidently identified as belonging exclusively to the provider cone as possible. When a blocklist-based SAV mechanism is applied, incoming data packets with source addresses covered by the blocklist are blocked. In practice, network operators may choose between blocklist-based and allowlist-based SAV mechanisms based on their operational requirements, deployment constraints, and risk considerations. Readers are 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. Improper Permit: The validation results that the packets with illegitimate source addresses are permitted improperly due to inaccurate SAV filters. Provider Cone: The set of ASes an AS can reach by using only Customer-to-Provider (C2P) links. Customer Cone: The set of ASes an AS can reach by using only Provider-to-Customer (P2C) links.

Improper Block When the Allowlist is Incomplete The fundamental idea of existing allowlist-based SAV solutions is to generate an ingress allowlist using information related to the customer cone of a customer or lateral peer AS. Specifically, these mechanisms identify prefixes belonging to the corresponding customer cone and permit only data packets with source addresses drawn from these prefixes on the interface facing that customer or lateral peer AS. This is based on the assumption that data packets received from a customer or lateral peer AS are expected to use source addresses belonging to the customer cone of that AS, unless a route leak occurs . Limited propagation of prefixes or the presence of hidden prefixes can result in an incomplete allowlist, which may in turn lead to improper blocking (see ).

An example of limited propagation of prefixes in the customer cone illustrates a case of limited prefix propagation within the customer cone of AS4. In the figure, arrows indicate both the propagation direction of BGP announcements and the AS relationships, namely Provider-to-Customer (P2C), Customer-to-Provider (C2P), and Peer-to-Peer (P2P), from the sending AS to the receiving AS. AS1 announces routes for prefixes P1 and P2 to its two provider ASes, AS2 and AS3. However, AS1 attaches NO_EXPORT to the BGP UPDATE message sent to AS2, preventing AS2 from propagating the routes further to AS4. As a result, AS4 receives routes to prefixes P1 and P2 only from its lateral peer or provider AS5. If AS4 applies EFP-uRPF, including Algorithm A or Algorithm B, to generate an allowlist on the AS4–AS2 interface, the allowlist will not include prefixes P1 and P2. Consequently, data packets with source addresses in prefixes P1 or P2 will be improperly blocked.

An example of hidden prefixes in the customer cone shows an example of hidden prefixes in Content Delivery Network (CDN) and Direct Server Return (DSR) scenarios. AS6, where the anycast server is located, announces a route to the anycast prefix P3. Although AS1, where the edge server is located, is not authorized to originate routes for prefix P3, it legitimately sends data packets using source addresses in prefix P3 as a result of DSR. If AS4 applies an allowlist on the AS4–AS2 interface, the allowlist will not include prefix P3. Therefore, the allowlist filter on the AS4–AS2 interface will improperly block data packets with source addresses in prefix P3. More recent SAV mechanisms, such as BAR-SAV , additionally leverage Autonomous System Provider Authorization (ASPA) and Route Origin Authorization (ROA) related to the customer cone to construct a more robust allowlist. Traffic Origin Authorization (TOA) can further improve allowlist completeness in hidden-prefix scenarios. However, such authoritative information may be missing due to partial deployment, operational constraints, or incremental adoption. When some ASes or prefixes lack ASPAs, ROAs, or TOAs, the resulting allowlist may still be incomplete. In summary, due to the inherent complexity of inter-domain routing, SAV mechanisms that rely on allowlist filters on interfaces facing customer or lateral peer ASes may fail to identify all prefixes belonging to the corresponding customer cone. In such cases, an incomplete allowlist can lead to improper blocking of legitimate traffic.

Allowlist-based and Blocklist-based SAV Approaches As discussed in , allowlist-based SAV mechanisms may improperly block legitimate traffic when authoritative information is missing or incomplete. More generally, ingress SAV mechanisms can be categorized as allowlist-based or blocklist-based, depending on how authoritative information is used in filtering decisions. An allowlist-based approach permits incoming packets only when their source addresses are explicitly authorized by available authoritative information. When the authoritative information is complete, an allowlist-based approach introduces neither improper blocking nor improper admits. However, when authoritative information is missing, legitimate traffic may be improperly blocked. A blocklist-based approach, in contrast, permits incoming packets by default and blocks only those packets whose source addresses are explicitly identified as unauthorized by authoritative information. As a result, a blocklist-based approach does not improperly block legitimate traffic when authoritative information is missing, but may result in improper admits if unauthorized source addresses are not covered by the blocklist. Therefore, when authoritative information is incomplete, allowlist-based and blocklist-based approaches represent different trade-offs. Allowlist-based approaches prioritize minimizing improper permits at the risk of improper blocking, whereas blocklist-based approaches prioritize avoiding improper blocking at the risk of improper permits.

Goals of Bicone SAV Bicone SAV aims to provide robust ingress source address validation on interfaces facing customer or lateral peer ASes by appropriately selecting between allowlist-based and blocklist-based filtering. Its design goals are as follows:

Avoiding improper blocks. Bicone SAV prioritizes avoiding the blocking of legitimate data packets received from customer or lateral peer ASes. When authoritative information is insufficient to construct a complete allowlist, Bicone SAV prefers mechanisms that avoid improper blocking.
Maintaining directionality. Bicone SAV seeks to preserve directionality in ingress filtering in order to effectively identify source-spoofed data packets. When sufficient authoritative information is available, stricter filtering can be applied to improve spoofing detection.

Blocklist Generation This section describes how to generate a blocklist using BGP UPDATE messages, ASPAs, ROAs, and TOAs associated with the provider cone.

Key Idea The provider cone of an AS is defined as the set of ASes that the AS can reach by traversing only Customer-to-Provider (C2P) links. In the absence of route leaks , prefixes associated with ASes in the provider cone are not expected to be used as source addresses in data packets received from customer or lateral peer ASes. Accordingly, the blocklist consists of prefixes that belong to the provider cone. When the blocklist is applied on an interface facing a customer or lateral peer AS, data packets received on that interface are discarded if their source addresses match any prefix in the blocklist. To construct such a blocklist, an AS first identifies the ASes in its provider cone using ASPAs and AS-PATH information carried in BGP UPDATE messages. It then identifies prefixes associated with these ASes using ROAs and TOAs . Prefixes that also belong to the AS’s customer cone are subsequently removed from consideration. Given the inherent uncertainty in determining whether a prefix belongs to the customer cone, as discussed in , a conservative strategy is to retain only prefixes that are exclusively associated with the provider cone. By blocking traffic that uses these prefixes as source addresses, the resulting blocklist-based SAV filter can mitigate the improper blocking issues observed in allowlist-based SAV filters, while still preserving directionality.

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 or ASN_{i+1} is a Tier-1 AS, 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 and TOAs 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 and TOAs. Call it Prefix-set S.
For each unique Prefix P in Prefix-set S, check origin ASNs of Prefix P by using all ROAs and TOAs. If all unique Prefixes in Prefix-set S have been processed, go to Step 15.
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 S. Go to Step 13.
Apply Prefix-set S as a blocklist on interfaces facing a customer or lateral peer AS.

Incremental and Partial Deployment of ASPAs Under incremental and partial deployment of ASPAs, an AS may be unable to fully identify all ASes in its provider cone. As a result, the resulting blocklist may not include all prefixes associated with the provider cone. Nevertheless, an incomplete blocklist does not lead to improper blocking of legitimate traffic. Instead, it can still filter source-spoofed packets whose source addresses fall within the identified subset of provider-cone prefixes. Therefore, even with partial ASPA deployment, the blocklist can provide immediate incremental benefits without introducing additional operational risk.

Incremental and Partial Deployment of ROAs and TOAs This document does not use BGP UPDATE messages as a data source for determining the source address space associated with an AS. As discussed in , BGP information may be incomplete due to limited propagation or hidden prefixes, which can lead to improper blocking when used for SAV filtering. Instead, this document relies on Route Origin Authorizations (ROAs) and Traffic Origin Authorizations (TOAs) as authoritative information for identifying source address space. Because ROAs and TOAs are explicitly registered by prefix holders and are independent of BGP propagation behavior, they are not affected by the invisible scenarios described in . Under incremental and partial deployment, ROAs and TOAs may be missing for some prefixes. If a prefix does not have any corresponding ROA or TOA, it will not be included in the generated blocklist. Consequently, missing ROAs or TOAs do not result in improper blocking of legitimate traffic, although they may reduce the effectiveness of blocking spoofed packets. This document assumes correct operational practice by prefix holders: once ROAs or TOAs are registered for a prefix, the registration is complete and accurately reflects all legitimate route origins or traffic origins for that prefix.

Implementation and Operations Considerations Network operators may choose to deploy either allowlist or blocklist filters on interfaces facing different customer or lateral peer ASes, depending on their operational requirements and deployment conditions.

Meeting the Goals Avoiding improper blocking is a primary operational objective, as discarding legitimate traffic can cause severe service disruption. Subject to this constraint, SAV mechanisms should also minimize improper admits to improve protection against source address spoofing. When an allowlist deployed on an interface is known to be complete, it introduces neither improper blocks nor improper admits. However, if allowlist completeness cannot be reliably ensured, for example due to hidden prefixes in the customer cone or missing authoritative information, deploying an allowlist may lead to improper blocking of legitimate traffic and thus fail to meet the primary objective. In contrast, a blocklist does not result in improper blocking caused by missing authoritative information, although it may allow some spoofed traffic when incomplete. Accordingly, when an allowlist on an interface is known to be complete, network operators are advised to use the allowlist. Otherwise, deploying a blocklist is recommended to avoid potential improper blocking. For small ISPs with relatively small customer cones, determining allowlist completeness is generally easier, as fewer ASes are involved and routing relationships tend to be simpler. For example, operators may directly confirm with a customer or lateral peer AS whether all ASes in its customer cone have deployed the required authoritative information. In contrast, for large ISPs with extensive customer cones, determining allowlist completeness is significantly more challenging. In such cases, if the completeness of the allowlist cannot be reliably determined, deploying a blocklist is recommended.

Storage Overhead Deploying allowlist or blocklist filters requires additional memory resources, such as ternary content-addressable memory (TCAM), on line cards. Network operators should therefore consider storage overhead when selecting between allowlists and blocklists. In general, a small ISP tends to generate a smaller allowlist and a larger blocklist, while a large ISP tends to generate a larger allowlist and a smaller blocklist. One approach to reducing memory consumption is to maintain the original list in the control plane and install only an aggregated list in the data plane. For example, if the original list contains prefixes P1 and P2, and P1 is a less-specific prefix of P2, only P1 needs to be installed in the data plane.

Implementation and Operations Recommendations For an interface facing a customer or lateral peer AS, the following operational guidance applies:

If the network operator can determine that the allowlist covers all prefixes of the corresponding customer cone, deploying an allowlist on the interface is recommended, as a complete allowlist introduces neither improper blocks nor improper permits.
If the network operator cannot reliably determine the completeness of the allowlist, deploying a blocklist is recommended in order to avoid improper blocking. In such cases, operators are encouraged to consider using the blocklist in conjunction with Loose uRPF to improve spoofed traffic mitigation. Loose uRPF can be used to filter packets with unallocated or unroutable source addresses, while the blocklist focuses on filtering packets whose source addresses are associated with the provider cone.

Network operators may further refine the blocklist based on local knowledge. For example, operators may add special-purpose prefixes that are not expected to be used as source addresses in data packets, such as those listed in the 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.