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 allowlists on interfaces facing customer or lateral peer Autonomous Systems (ASes). These allowlists are generated using information related to the customer cone of the neighboring AS. Under a conventional allowlist-based approach, an interface permits incoming packets only if their source addresses are covered by the allowlist. Consequently, if the allowlist is incomplete, legitimate traffic whose source prefixes are missing from the allowlist may be improperly blocked. An incomplete allowlist nevertheless provides useful positive information. A source address covered by the allowlist can be identified as legitimate for the corresponding ingress interface. However, when the allowlist is incomplete, absence from the allowlist is not sufficient evidence that a source address is spoofed, because the absence may be caused by limited route propagation, hidden prefixes, or incomplete deployment of authoritative information. Bicone SAV therefore jointly uses an allowlist and a blocklist. The allowlist provides positive evidence that a source address is legitimate. The blocklist provides positive evidence that a source address is inappropriate on the corresponding ingress interface and can therefore be treated as spoofed. The blocklist described in this document is primarily constructed from prefixes that are exclusively associated with the provider cone. It can also be augmented with appropriately selected denylist prefixes derived from customer-cone information, such as the special purpose denylists described in . When the allowlist is incomplete, Bicone SAV applies three-way handling. Packets whose source addresses are covered by the allowlist are permitted. Packets whose source addresses are not covered by the allowlist but are covered by the blocklist are discarded. Packets whose source addresses are covered by neither list are treated as unverified and are permitted with logging or other suitable monitoring. Operators can subsequently analyze the monitored traffic to determine whether the source addresses correspond to legitimate prefixes missing from the allowlist, operational anomalies, or spoofing activity. 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. Unverified Source Address: A source address that is not covered by an incomplete allowlist and is not positively identified as spoofed by the blocklist.

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.

Joint Use of Allowlist and Blocklist As discussed in , an allowlist constructed from customer-cone information may be incomplete. In that case, an allowlist match provides positive evidence that the source address is legitimate on the corresponding ingress interface, but an allowlist miss does not by itself prove that the source address is spoofed. A blocklist provides the complementary type of information. It contains prefixes that can be positively identified as inappropriate for use as source addresses on the corresponding ingress interface. A packet whose source address matches the blocklist can therefore be treated as source-spoofed and discarded. When the allowlist is known to be complete, conventional allowlist enforcement can be applied: packets whose source addresses are covered by the allowlist are permitted and other packets are discarded. When the allowlist is incomplete or its completeness cannot be reliably determined, Bicone SAV jointly applies the allowlist and blocklist as follows:

If the source address is covered by the allowlist, the packet is considered legitimate and is permitted.
Otherwise, if the source address is covered by the blocklist, the packet is considered spoofed on the corresponding ingress interface and is discarded.
Otherwise, the source address is unverified. The packet is permitted with logging or other suitable monitoring for subsequent analysis.

Thus, Bicone SAV does not treat absence from an incomplete allowlist as sufficient grounds for discarding traffic. The allowlist is still useful for positively identifying legitimate source addresses, while the blocklist enables positively identified spoofed traffic to be discarded. The remaining traffic is explicitly treated as uncertain rather than being forced into either classification. If a source address is simultaneously covered by both the allowlist and the blocklist, the available SAV information is inconsistent. Such a conflict should be exposed to the operator for investigation. To avoid improper blocking, an implementation SHOULD NOT automatically discard packets solely on the basis of the conflicting information.

Goals of Bicone SAV Bicone SAV aims to provide robust ingress source address validation on interfaces facing customer or lateral peer ASes by jointly using customer-cone and provider-cone information. Its design goals are as follows:

Avoiding improper blocks. Bicone SAV does not treat absence from an incomplete allowlist as sufficient evidence of source address spoofing. Traffic whose source legitimacy cannot be conclusively determined is permitted rather than discarded.
Filtering positively identified spoofed traffic. Bicone SAV uses a blocklist to identify source prefixes that are inappropriate on the corresponding ingress interface. Packets matching such prefixes can be discarded even when the allowlist is incomplete.
Retaining useful information from incomplete allowlists. Entries contained in an incomplete allowlist remain useful positive evidence of legitimate source addresses and are therefore still used by Bicone SAV.
Supporting analysis of unverified traffic. Packets whose source addresses are covered by neither an incomplete allowlist nor the blocklist are permitted with logging or other suitable monitoring, allowing operators to investigate the traffic and improve the information used for SAV.

Blocklist Generation This section describes how to generate a blocklist using provider-cone information and how the resulting blocklist can be augmented using denylist information derived from customer cones.

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 exclusively with ASes in the provider cone are not expected to be used as source addresses in packets received from customer or lateral peer ASes. Such prefixes can therefore be included in the blocklist applied on those interfaces. To construct this part of the blocklist, an AS first identifies 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 may also legitimately be associated with ASes outside the provider cone are removed from consideration. The resulting set contains prefixes that can be conservatively treated as provider-cone-use-only prefixes. The blocklist can also be augmented with denylist information derived from customer cones. In particular, Section 5 of BAR-SAV describes a special purpose denylist computed for a customer interface. Such a denylist contains prefixes that are determined to apply exclusively to that customer interface or its customer cone and can therefore be used as a denylist on other interfaces. For a given customer or lateral peer interface, Bicone SAV can add appropriately selected prefixes from these BAR-SAV special purpose denylists to the blocklist when those prefixes are determined not to be legitimate source prefixes on the interface under consideration. The two sources of blocklist information are complementary. Provider-cone information identifies prefixes that are inappropriate on customer and lateral peer interfaces because they belong exclusively to the provider direction. BAR-SAV special purpose denylists identify prefixes that are inappropriate on a particular interface because they belong exclusively to another customer direction. In both cases, a prefix is added to a blocklist only when available information is sufficient to positively identify it as inappropriate on that ingress interface.

Generation Procedure A detailed description of the provider-cone-based 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 authorized origin ASN not in AS-set Z(k_max), remove the prefix from Prefix-set S. Go to Step 13.
For each interface facing a customer or lateral peer AS, initialize the interface blocklist with Prefix-set S.
If special purpose denylists are available from the procedure described in Section 5 of BAR-SAV , appropriately select the denylists that identify prefixes as exclusive to other customer interfaces or customer cones. Add those prefixes to the blocklist of the interface under consideration.
Apply the resulting blocklist on the interface facing the customer or lateral peer AS.

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 .

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.

Security Considerations The security considerations described in , , , , and also apply 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.