| Internet-Draft | Bicone SAV | August 2026 |
| Qin, et al. | Expires 18 February 2027 | [Page] |
Source address validation (SAV) aims to detect source-spoofed traffic while avoiding improper blocking of legitimate traffic. Existing SAV mechanisms commonly rely on ingress allowlist filters on interfaces facing customer or lateral peer Autonomous Systems (ASes). When such an allowlist is incomplete, a source address not covered by the allowlist cannot be conclusively identified as spoofed, because legitimate source prefixes may be missing from the allowlist. This document describes Bicone SAV, which jointly uses an allowlist derived from customer-cone information and a blocklist containing prefixes that can be positively identified as inappropriate on the corresponding ingress interface. When the allowlist is incomplete, packets matching the allowlist are permitted, packets matching the blocklist are discarded, and packets matching neither list are permitted with logging or other monitoring for subsequent analysis. The blocklist can be constructed from provider-cone information and augmented with denylist information derived from customer cones.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC2827] and BCP84 [RFC3704] [RFC8704]. A fundamental design objective of SAV mechanisms is to minimize improper blocking, that is, blocking legitimate traffic, while preserving directionality, as discussed in [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704].¶
Existing advanced SAV mechanisms, such as EFP-uRPF [RFC8704] and BAR-SAV [I-D.ietf-sidrops-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 [I-D.ietf-sidrops-bar-sav].¶
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 [I-D.ietf-savnet-inter-domain-problem-statement], [RFC8704], [I-D.ietf-sidrops-aspa-profile], [RFC6482], [I-D.ietf-sidrops-aspa-verification], and [I-D.qin-savnet-toa].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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 [RFC7908].¶
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 [I-D.ietf-savnet-inter-domain-problem-statement]).¶
P1[AS5 AS3 AS1]
P2[AS5 AS3 AS1]
+---------+ (P2P/P2C) +---------+
| AS4 +<----------+ AS5 |
+---------+ +---------+
/\ /\
P1 and P2 not / / P1[AS3 AS1]
propagated / / P2[AS3 AS1]
(C2P) / / (C2P)
+---------+ +---------+
| AS2 | | AS3 |
+---------+ +---------+
/\ /\
P1[AS1] NO_EXPORT \ / P1[AS1]
P2[AS1] NO_EXPORT \ / P2[AS1]
(C2P) \ / (C2P)
+---------+
| AS1 |
+---------+
P1, P2 (prefixes originated)
Figure 1 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.¶
P3 (anycast prefix)
+---------+
| AS6 |-Anycast Server
+---------+
|
P3[AS6] |
(P2C) |
\/
+---------+ (P2P/P2C) +---------+
| AS4 +<----------+ AS5 |
+---------+ +---------+
/\ /\
/ /
(C2P) / / (C2P)
/ /
+---------+ +---------+
| AS2 | | AS3 |
+---------+ +---------+
/\ /\
\ /
(C2P) \ / (C2P)
\ /
+---------+
| AS1 |-Edge Server
+---------+
(AS1 never announces the route to P3)
Figure 2 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 [I-D.ietf-sidrops-bar-sav], additionally leverage Autonomous System Provider Authorization (ASPA) [I-D.ietf-sidrops-aspa-profile] and Route Origin Authorization (ROA) [RFC6482] related to the customer cone to construct a more robust allowlist. Traffic Origin Authorization (TOA) [I-D.qin-savnet-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.¶
As discussed in Section 3, 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.¶
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.¶
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.¶
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 [RFC7908], 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 [I-D.qin-savnet-toa]. 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 [I-D.ietf-sidrops-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.¶
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 [I-D.ietf-sidrops-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 [IANA].¶
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.¶
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 Section 3, 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) [RFC6482] and Traffic Origin Authorizations (TOAs) [I-D.qin-savnet-toa] 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 Section 3.¶
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.¶
The security considerations described in [RFC8704], [I-D.ietf-sidrops-bar-sav], [I-D.ietf-sidrops-aspa-profile], [RFC6482], and [I-D.ietf-sidrops-aspa-verification] also apply to this document.¶
This document has no IANA requirements.¶
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.¶