Provider Interface SAV for Customer Cone Sources
draft-huang-savnet-pi-sav-for-cc-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mingqing(Michael) Huang , Nan Geng , Dan Li | ||
| Last updated | 2026-06-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huang-savnet-pi-sav-for-cc-02
savnet M. Huang
Internet-Draft Zhongguancun Laboratory
Intended status: Informational N. Geng
Expires: 26 November 2026 Huawei Technologies
D. Li
Tsinghua University
25 May 2026
Provider Interface SAV for Customer Cone Sources
draft-huang-savnet-pi-sav-for-cc-02
Abstract
Current source address validation (SAV) on an AS's provider
interfaces mainly relies on loose uRPF, which cannot defend against
IP spoofing using routable prefixes and is ineffective when a default
route is present. This document describes a *framework* for provider
interface source address validation against spoofing of customer cone
source prefixes (PI-SAV for CC). Two architectural approaches are
presented:
* *PI-SAV for Standalone CC*: a static solution that builds a
blocklist based on topology information from BGP RIBs, RPKI ASPA,
and local configuration (SLURM) etc. It requires no inter-AS
communication.
* *PI-SAV for Standalone+ CC*: an enhanced solution that uses
lightweight query-response coordination between the top AS and
member ASes to identify sub-cones that do not actually cause
traffic detours, thereby enlarging the effective blocklist.
This document is *informational* and provides only the framework,
conceptual procedures, and requirements for future protocol
specifications. Detailed wire protocols (e.g., for partial transit
information provisioning or for query-response messaging) are out of
scope and will be defined in separate documents.
Status of This Memo
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/.
Huang, et al. Expires 26 November 2026 [Page 1]
Internet-Draft PI-SAV for CC Sources May 2026
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 26 November 2026.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Basic Solution: PI-SAV for Standalone CC . . . . . . . . . . 5
2.1. General Procedure for SCC Solution . . . . . . . . . . . 5
2.2. Requirements for SCC Solution . . . . . . . . . . . . . . 6
2.2.1. Complete Member AS Discovery (Hidden ASes) . . . . . 6
2.2.2. Detection of Alternative Transit Providers . . . . . 7
2.2.3. MOAS Prefix Handling . . . . . . . . . . . . . . . . 8
3. Improved Solution: PI-SAV for Standalone+ CC . . . . . . . . 9
3.1. Motivations and Operational Assumptions . . . . . . . . . 9
3.2. Query-Response Coordination Model . . . . . . . . . . . . 9
3.3. Requirements for a Future Communication Protocol . . . . 10
4. Deployment and Management Considerations . . . . . . . . . . 11
4.1. Data Completeness Requirements . . . . . . . . . . . . . 12
4.2. Incremental Deployment and Blind Spots . . . . . . . . . 12
4.3. Independence Degree as a Metric . . . . . . . . . . . . . 13
4.4. Feedback-Driven Refinement . . . . . . . . . . . . . . . 13
5. Future Work: Protocol Specification Roadmap . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Huang, et al. Expires 26 November 2026 [Page 2]
Internet-Draft PI-SAV for CC Sources May 2026
1. Introduction
As described in [RFC3704], [RFC8704], and
[I-D.ietf-savnet-inter-domain-problem-statement], current source
address validation on AS provider interfaces is mainly based on the
loose uRPF mechanism. This mechanism can only check whether the
source address is a valid internet prefix but cannot provide
protection for routable prefixes spoofing. Furthermore, if the AS
has a default route (many stub ASes configure default routes to
reduce BGP processing and FIB table pressure), the protective effect
of loose uRPF on routable prefixes will also be nullified.
Meanwhile, normally the vast majority of DDoS attack traffic flows
into the local network through the provider interface side. Studies
further indicate that reflective amplification attacks based on
source address spoofing are among the most prevalent types of large-
scale DDoS attacks.
The solutions described in this document, based on the customer cone
(CC) source address information and its routing characteristics,
generate the provider interface based source prefix blocklist for the
customer cone prefixes (IBB-mode in
[I-D.ietf-savnet-general-sav-capabilities], or IBA-mode combined with
loose uRPF if applicable). The design goal is to prevent spoofing
packets with the customer cone prefixes from flowing into the local
networks, which can reduce the threat of reflective amplification
DDoS attacks that leverage local servers to target local users.
This document is intentionally limited to an *informational
framework*. It describes the solution architecture, operational
assumptions, and requirements for both Standalone CC and Standalone+
CC. The actual protocols for obtaining partial transit information
(Section 2.2) and for query-response coordination (Section 3.3) are
left for future specifications. This approach allows the community
to review and agree on the overall design before committing to
protocol details.
1.1. Terminology
Customer Cone (CC): a set of ASes that includes an AS and its direct/
indirect customer ASes, including the customer AS's customer ASes and
so on, till the stub ASes.
CC-Top-AS: the top AS for the customer cone, which means all other
ASes in the CC are its direct/indirect customer ASes.
Huang, et al. Expires 26 November 2026 [Page 3]
Internet-Draft PI-SAV for CC Sources May 2026
CC-Top-ASBR: ASBR (AS Border Router) with the provider interface(s)
of the CC-Top-AS, which is the deployment position for the solutions
in this document.
CC-Member-AS: an AS in the customer cone under the CC-Top-AS.
Partial Transit: a special transit provider service between two eBGP
neighbors, a less common but operationally significant scenario.
When an AS (AS-a) receives BGP update messages from its customer AS
(AS-b), it disseminates the messages only to its peer AS(es) and
other customer AS(es), not to its upper transit providers as usual.
In this case, AS-a is partial transit provider for AS-b. Partial
transit can make the customer AS (and its sub-CC) invisible for the
upper transit AS.
CC-sub-Transit-AS: a CC-Member-AS that has alternative transit
provider(s) outside the CC.
Sub-Transit-CC: the customer cone of a CC-sub-Transit-AS (including
the CC-sub-Transit-AS and its direct/indirect customer ASes).
According valley-free policy of BGP routing, traffic from the Sub-
Transit-CC to other CC-Member-AS may go through the alternative
transit link and provider interfaces of CC-Top-ASBR.
Standalone CC (SCC): a subset of CC, all ASes within a Standalone CC
share same transit provider(s) on the CC-Top-AS (i.e. no member AS of
a Standalone CC has an alternative transit provider outside the CC),
all Sub-Transit-CCs in the CC must be excluded. Based on the valley-
free principle of BGP routing, traffic between Standalone CC hosts
will not go through the CC-Top-AS's provider interfaces.
Standalone+ CC (SPCC): a superset of a Standalone CC that includes
the Sub-Transit-CC(s) for which no detour actually occurs for intra-
CC traffic. In other words, traffic between Standalone+ CC hosts
will not go through the provider interfaces of the CC-Top-AS. Note
that the range of Standalone+ CC may change dynamically due to
traffic engineering configuration or transit link failure.
Detour Path: in the context of this document, a detour path refers to
a route taken by intra-CC traffic that enters the CC via a provider
interface of the CC-Top-AS (i.e., the traffic flows from an external
alternative provider into the CC). Such a path makes the
corresponding source prefix unsuitable for the PI-SAV blocklist,
because legitimate packets with that source prefix may enter the CC
through that interface.
Huang, et al. Expires 26 November 2026 [Page 4]
Internet-Draft PI-SAV for CC Sources May 2026
Independence Degree: a metric that evaluates the degree of
independence of a Standalone CC or Standalone+ CC within its customer
cone, defined as the percentage of IP prefixes inside the CC that
qualify as belonging to the Standalone CC or Standalone+ CC. A
higher Independence Degree indicates that a larger fraction of the
customer cone's prefixes can be protected from spoofing via the
provider interface blocklist.
1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Basic Solution: PI-SAV for Standalone CC
2.1. General Procedure for SCC Solution
The PI-SAV for Standalone CC solution focuses on constructing the
Standalone CC by deducting Sub-Transit-CCs from the whole CC without
omission, and then generating a source prefix blocklist for the
Standalone CC (after subtracting prefixes with multiple origin ASes).
Standalone CC construction requires complete knowledge of the CC-
Member-ASes and whether each of them has an alternative transit
provider outside the CC. The general procedure for a CC-Top-ASBR to
generate the PI-SAV blocklist for Standalone CC is as follows:
1. *Initial CC-Member-AS collection*: includes (a) ASNs for all
direct customer ASes of the CC-Top-AS (obtained from system
configuration), and (b) partial transit deployment information
for the target CC (using SLURM-based local management as
suggested).
2. *CC construction*: based on the initial ASNs, find all CC-Member-
ASes by searching the local-RIBs for ASes that appear under the
initial ASN in the AS-PATHs. The transit relationship between
member ASes must be saved for later Sub-Transit-CC construction.
Huang, et al. Expires 26 November 2026 [Page 5]
Internet-Draft PI-SAV for CC Sources May 2026
3. *Sub-Transit-CC construction*: check whether any alternative
transit provider outside the CC exists for each CC-Member-AS. If
such a provider exists, mark the AS as a CC-sub-Transit-AS. This
can be done using RPKI ASPA records
[I-D.ietf-sidrops-aspa-profile], and local SLURM-based support
for additional information is encouraged. If the transit
provider information is not available for a CC-Member-AS, the AS
MUST be marked as a CC-sub-Transit-AS. Then construct the Sub-
Transit-CC for each CC-sub-Transit-AS.
4. *Standalone CC construction*: deduct all the Sub-Transit-CCs from
the original CC to form the Standalone CC.
5. *Initial prefix list generation*: based on local-RIBs, collect
all prefixes originated from the member ASes of the Standalone
CC.
6. *Final prefix blocklist generation*: check whether any prefix in
the initial list has multiple origin ASes (MOAS). If a prefix is
originated not only by AS(es) inside the CC but also by AS(es)
outside the CC, deduct it from the initial list. MOAS prefix
identification can be based on RPKI ROA [RFC9582] and/or local
ROA SLURM records. BGP adj-RIBs-in can also be used to identify
external origins.
2.2. Requirements for SCC Solution
The Standalone CC solution relies on three distinct types of
information to correctly construct the blocklist. Each is described
below as a set of requirements, independent of any particular
implementation or external database (e.g., RPKI ASPA). This
separation ensures that the framework remains implementation-agnostic
and can be satisfied by different mechanisms (e.g., local
configuration, future protocols, or a combination).
2.2.1. Complete Member AS Discovery (Hidden ASes)
The CC-Top-AS must know the full set of CC-Member-ASes, including
those that may be invisible from local-RIBs due to partial transit
relationships or No-Export BGP communities.
*Requirements*:
* *Observability gap*: BGP local-RIBs alone is insufficient to
guarantee a complete view. Hidden ASes (child ASes that do not
advertise their prefixes upward) cannot be automatically inferred.
Huang, et al. Expires 26 November 2026 [Page 6]
Internet-Draft PI-SAV for CC Sources May 2026
* *Explicit provisioning*: If a CC-Member-AS engages in partial
transit or otherwise hides its prefixes from the CC-Top-AS, the
operator of the CC-Top-AS MUST explicitly supply this information,
e.g., via local SLURM [RFC8416] entries or a future declarative
protocol. The CC-Top-AS cannot "assume" a hidden subtree; it can
only act on explicitly known information.
* *Future specification*: A future specification document MAY define
a mechanism (e.g., an extension to RPKI ASPA or a BGP attribute)
for an AS to voluntarily declare its partial transit
relationships, thereby making hidden ASes discoverable. Until
such a mechanism exists, operators must rely on local
configuration.
* *Handling missing information*: If the CC-Top-AS lacks information
about whether a particular customer AS has hidden downstream ASes,
it is impossible to make a safe assumption for Standalone CC - the
construction of Sub-Transit-CC related to the hidden AS might be
omitted. Therefore, operators MUST ensure that no partial transit
information is missing, either via local configuration or a future
specification; otherwise, they MUST use the Standalone+ CC
solution (Section 3), which can dynamically discover hidden ASes
through the diffusion-based query mechanism (R7 in Section 3.3).
This requirement ensures that SCC is deployed only where topology
information is complete, avoiding unsafe default assumptions.
2.2.2. Detection of Alternative Transit Providers
For each CC-Member-AS, the CC-Top-AS must determine whether that AS
has any transit provider outside the CC. Such ASes are marked as CC-
sub-Transit-AS, and their entire sub-cone is excluded from the
Standalone CC.
*Requirements*:
* *Provider set completeness*: The CC-Top-AS MUST obtain the set of
all transit providers for each CC-Member-AS. This can be done
using RPKI ASPA records [I-D.ietf-sidrops-aspa-profile], local
SLURM, or other means.
* *Safe default - assume external provider*: If the provider
information for a CC-Member-AS is incomplete or unavailable (e.g.,
no ASPA record and no local override), the CC-Top-AS MUST assume
that the AS has an external transit provider and therefore MUST
mark it as a CC-sub-Transit-AS. This ensures that the blocklist
never incorrectly includes prefixes that might have a feasible
detour path.
Huang, et al. Expires 26 November 2026 [Page 7]
Internet-Draft PI-SAV for CC Sources May 2026
2.2.3. MOAS Prefix Handling
A prefix originated by multiple ASes (MOAS) MUST be excluded from the
blocklist only if at least one of its origin ASes lies outside the
Standalone CC. If all origin ASes are inside the Standalone CC, the
prefix MAY remain in the blocklist (internal MOAS does not create a
detour path).
Detecting external origins is challenging due to two inherent
limitations:
* *Best-path-only visibility*: BGP best path selection hides
alternate origin ASes from the Loc-RIBs (Adj-RIBs-in may also be
missing).
* *Adj-RIBs-in incompleteness*: Memory-constrained routers may not
retain a full Adj-RIBs-in.
*A practical deployment* SHOULD combine the following information
sources:
* *RPKI ROA* - Preferred when valid records exist.
* *Local SLURM* - Operator-provided overrides (especially for
critical prefixes).
* *BGP Adj-RIBs-in* - Usable as a supplementary signal, with
recognition that it may be incomplete.
If external origin information is incomplete, the operator MAY choose
a local policy:
* *Conservative (RECOMMENDED)*: Exclude the prefix from the
blocklist unless it can be confidently determined that no external
origin exists. This avoids false blocking at the cost of reduced
protection.
* *Optimistic*: Include the prefix in the blocklist unless an
external origin is positively confirmed. This maximizes
protection but risks blocking legitimate traffic if an unknown
external origin exists.
Operators should weigh the impact of false blocking (denial of
service for legitimate customers) versus under-protection (spoofing
risk). Feedback from deployment (see Section 4.5) can help refine
the information over time.
Huang, et al. Expires 26 November 2026 [Page 8]
Internet-Draft PI-SAV for CC Sources May 2026
3. Improved Solution: PI-SAV for Standalone+ CC
3.1. Motivations and Operational Assumptions
Although an alternative transit link may cause traffic between CC
member ASes to detour through provider interfaces of the CC-Top-AS,
such detours normally only happen under specific routing policy
configurations or internal transit path failures. In many cases,
Sub-Transit-CCs do not actually use their external providers for
intra-CC traffic.
Standalone+ CC relaxes the strict exclusion of all Sub-Transit-CCs.
Instead, it verifies whether detours actually occur, and includes
those Sub-Transit-CCs (or even finer-grained prefixes) that have no
detour. This can significantly improve the prefix independence
ratio, especially for deep customer cones.
The Standalone+ CC solution assumes a communication mechanism between
the CC-Top-AS and CC-Member-ASes. This document only describes the
conceptual model and the requirements for such a communication
protocol; the actual protocol design is left for future Standards
Track documents.
3.2. Query-Response Coordination Model
In the conceptual model, the CC-Top-AS sends *queries* to member ASes
to determine whether detour paths actually exist. Two communication
approaches are possible:
* *Targeted queries*: The CC-Top-AS first constructs the CC topology
(using BGP RIB and possibly RPKI/ASPA) to identify which member
ASes have or may have alternative transit providers. It then
sends queries only to those CC-sub-Transit-ASes. This approach
requires pre-existing topology knowledge and connectivity
information for the targeted ASes.
* *Diffusion-based queries (recommended)*: The CC-Top-AS injects the
query into BGP (e.g., as a new BGP attribute or NLRI) and relies
on existing BGP propagation to deliver the query to *all* CC-
Member-ASes. This approach requires no pre-computed topology and
naturally reaches all ASes, including those that would otherwise
be hidden due to partial transit. Moreover, it allows member ASes
to respond not only with "no detour" indications but also with
auxiliary information (e.g., hidden AS, their provider set, MOAS
origins), thereby *replacing or complementing out-of-band
registries* (RPKI ASPA, ROA and SLURM etc.) for Standalone CC.
Huang, et al. Expires 26 November 2026 [Page 9]
Internet-Draft PI-SAV for CC Sources May 2026
The *diffusion-based model* is the recommended baseline for
Standalone+ CC, because it:
* Eliminates the need for pre-computed CC topology before queries,
* Reaches all member ASes without requiring their explicit
addresses,
* Enables incremental deployment (ASes that ignore the BGP attribute
simply do not respond; the CC-Top-AS then assumes a detour),
* Provides a unified channel for both detour detection and topology/
prefix information collection.
Two operational modes are defined, regardless of the underlying
communication model:
* *Conservative mode*: The CC-Top-AS starts with the Standalone CC
as the initial blocklist. It then sends a query to member ASes
(via the chosen mechanism). If a member AS responds that no
detour exists for its sub-cone (or for specific prefixes), the CC-
Top-AS adds the corresponding prefixes to the Standalone+ CC
blocklist. Non-responsive ASes are assumed to have a detour.
* *Aggressive mode*: The CC-Top-AS starts with the whole CC as the
initial blocklist. It then sends a query. If a member AS
responds that a detour does exist, the CC-Top-AS removes the
corresponding prefixes from the blocklist. Non-responsive ASes
are also treated as having a detour after a timeout. This mode
works best when most member ASes support the protocol.
The detailed timing, retransmission, and state machines depend on the
chosen communication model and are left for future specification.
The remainder of this document assumes the diffusion-based model as
the reference; the targeted model is considered an optional
simplification (e.g., for small-scale deployments).
3.3. Requirements for a Future Communication Protocol
The SPCC solution requires a communication mechanism between the CC-
Top-AS and CC-Member-ASes to exchange queries and responses. This
document does not define a protocol; instead, it lists the mandatory
requirements that any future Standards Track protocol MUST satisfy.
*R1 - Query dissemination*: The query MUST be deliverable to all CC-
Member-ASes without requiring the CC-Top-AS to pre-compute their
identities or addresses. A diffusion mechanism that leverages
existing BGP propagation (e.g., a new BGP attribute or NLRI) is
Huang, et al. Expires 26 November 2026 [Page 10]
Internet-Draft PI-SAV for CC Sources May 2026
RECOMMENDED. The query MUST include at least: - A unique query
identifier, - The mode (conservative or aggressive), - A timeout
value (default recommended 30 seconds), - Optionally, a list of
specific ASes or prefixes to be checked.
*R2 - Response collection*: A CC-Member-AS that receives a query MUST
be able to send a response back to the CC-Top-AS. The response MUST
include: - The same query identifier, - For each checked item, an
indication of whether a detour path is observed (or, in fine-grained
operation, a list of prefixes with no detour).
*R3 - Transport reliability*: The response channel MUST provide
reliable delivery (e.g., TCP). The query channel MAY use an
unreliable or reliable transport; if unreliable, the protocol MUST
define retransmission or fallback behavior.
*R4 - Security*: All communication MUST be authenticated and
encrypted to prevent forgery of "no detour" responses. Use of TLS
with router certificates is RECOMMENDED.
*R5 - Timeout and fallback*: If the CC-Top-AS does not receive a
response within the timeout, it MUST assume that a detour exists for
the corresponding ASes or prefixes (i.e., they are excluded from the
Standalone+ CC blocklist).
*R6 - Incremental updates*: To avoid obsolete blocklist entries that
could cause false blocking, a CC-Member-AS MUST send unsolicited
update messages to the CC-Top-AS when its routing state changes
(e.g., a previously direct path becomes a detour path, or a detour
path reverts to direct). The CC-Top-AS MUST NOT rely on periodic
polling.
*R7 - Auxiliary information collection*: In addition to detour
indications, the protocol MAY allow a CC-Member-AS to include in its
response other information that is useful for Standalone CC, such as:
- Its complete set of transit providers (including those outside the
CC), - Prefixes that are originated by it but hidden from the CC-Top-
AS (e.g., due to No-Export), - MOAS prefixes and their origin ASes.
This capability allows Standalone+ CC to gradually *replace* out-of-
band registries (Partial Transit, RPKI ROA/MOAS, RPKI ASPA, SLURM
etc.) for the purpose of constructing the initial Standalone CC
blocklist, thereby reducing deployment dependencies.
The detailed design of message formats, state machines, and IANA
registrations is left for future specification.
4. Deployment and Management Considerations
Huang, et al. Expires 26 November 2026 [Page 11]
Internet-Draft PI-SAV for CC Sources May 2026
4.1. Data Completeness Requirements
Deploying Standalone CC requires different levels of completeness for
different types of information:
* *Hidden ASes (complete subtree missing)* - This is the most
critical gap. If a whole AS (and its downstream) is invisible due
to partial transit, the operator MUST supply that information
(e.g., via SLURM) or use Standalone+ CC instead. Without it, the
blocklist may incorrectly retain prefixes that actually have a
detour path, causing false blocking.
* *Provider set (alternative transit providers)* - For any AS where
the operator provides explicit provider information (e.g., via
SLURM or ASPA), that information MUST be accurate and complete for
that AS. However, the operator is NOT required to provide
information for every AS; for ASes without explicit data, the safe
default (assume external provider) applies, which avoids false
blocking at the cost of reduced protection.
* *Prefix list (originated prefixes)* - The CC-Top-AS collects
prefixes from local-RIBs. Missing prefixes (e.g., due to No-
Export) simply reduce protection (the blocklist is smaller) and do
NOT cause false blocking. No completeness guarantee is required.
However, when a hidden AS is discovered (by explicit provisioning
or via Standalone+ CC), operators are encouraged to also retrieve
the complete prefix list of that AS to improve protection
coverage.
* *MOAS external origins* - As discussed in Section 2.2.3,
incomplete external origin information may lead to false blocking
if an optimistic policy is used, or under-protection if a
conservative policy is used. Operators should choose a policy
that matches their risk tolerance and use the feedback mechanism
(Section 4.5) to refine their information.
This graduated approach allows operators to deploy Standalone CC with
manageable assumptions, understanding where gaps are safe and where
they are not.
4.2. Incremental Deployment and Blind Spots
The solutions support incremental deployment within a region. Not
all member ASes need to support Standalone+ CC communication. For
those that do not, the CC-Top-AS MUST assume that detours exist
(i.e., exclude them from Standalone+ CC). Over time, as more ASes
adopt the protocol, the blocklist can expand.
Huang, et al. Expires 26 November 2026 [Page 12]
Internet-Draft PI-SAV for CC Sources May 2026
For Standalone CC, blind spots (e.g., hidden ASes due to partial
transit) can be addressed by local SLURM configuration. Operators
should prioritize configuring SLURM entries for customer ASes that
are known to have complex routing policies.
4.3. Independence Degree as a Metric
The Prefix Independence Degree defined in Section 1.1 can help
operators evaluate the potential benefit of PI-SAV for CC before
deployment. For example: - If the Independence Degree for Standalone
CC is high (e.g., >80%), the static solution already provides good
coverage. - If it is low for Standalone CC but high for Standalone+
CC (e.g., >80%), deploying Standalone+ CC (with the communication
protocol) is beneficial. - If both are low, the customer cone may be
too intertwined with external providers, and PI-SAV for CC may offer
limited protection.
These thresholds are illustrative; operators should determine their
own based on network topology and risk tolerance.
4.4. Feedback-Driven Refinement
The Standalone CC and Standalone+ CC solutions rely on static or
dynamically collected topology information. Incomplete information
(e.g., hidden ASes due to partial transit, unknown external
providers, or MOAS origins) can lead to suboptimal blocklists -
either under-protection or false blocking.
To address this, an operator MAY deploy a feedback loop that uses
*observed SAV validation results* to refine the information base.
This applies to all types of information gaps discussed in Section 2
(hidden ASes, alternative providers, MOAS), as well as incomplete
ASPA or SLURM entries.
*Example feedback loop*:
* *Detection*: The ASBR logs dropped packets (sampled) and their
source prefixes that are blocked by the PI-SAV blocklist. If a
prefix is frequently dropped but the operator later determines
that the traffic is legitimate (e.g., through customer reports or
traffic analysis), this indicates a possible false positive.
* *Investigation*: The operator investigates the topology around
that prefix. The investigation may reveal previously missing
information, such as an undisclosed external transit provider, a
hidden AS, or an unknown MOAS origin.
Huang, et al. Expires 26 November 2026 [Page 13]
Internet-Draft PI-SAV for CC Sources May 2026
* *Refinement*: The operator updates the local SLURM or, if using
Standalone+ CC, triggers a new query to collect fresh information.
The updated information is used to regenerate a more accurate
blocklist.
Conversely, if spoofed packets with a CC source prefix are observed
entering through a provider interface, that indicates the
corresponding prefix should have been excluded from the blocklist.
The operator can then similarly investigate and refine the
information base.
The feedback loop can be semi-automated:
* The ASBR exports sampled drop logs to an offline collector.
* An analytics process correlates drops with known topology and
flags anomalous patterns (e.g., a prefix that experiences a high
drop rate but has no known external provider).
* Alerts are raised for operator review and potential SLURM updates.
Over time, this iterative process helps the system converge to a more
accurate blocklist, compensating for initial information gaps.
5. Future Work: Protocol Specification Roadmap
This document intentionally does not define wire protocols for:
* Provisioning of partial transit information (see Section 2.2.1),
* Query-response coordination for Standalone+ CC (see Section 3.3).
The authors intend to collaborate with the SAVNET WG to produce one
or more Standards Track documents that specify these protocols.
Possible directions include:
* Extending RPKI ASPA to carry partial transit declarations,
* Defining a BGP attribute or a new NLRI for query dissemination
(the diffusion-based model described in Section 3.2),
* Designing a lightweight TCP-based protocol with TLS for responses.
Among the possible communication models, the diffusion-based (BGP-
integrated) approach is preferred for its scalability and ability to
also collect topology information. Future specifications may also
define a targeted query mode as a lightweight alternative.
Huang, et al. Expires 26 November 2026 [Page 14]
Internet-Draft PI-SAV for CC Sources May 2026
These future specifications will update or extend the framework
described in this document. Implementers are encouraged to
experiment with the framework and provide feedback.
6. Security Considerations
The security considerations for PI-SAV for CC mainly relate to the
communication mechanism for Standalone+ CC. As required in
Section 3.3, any future protocol MUST provide authentication and
encryption to prevent an attacker from forging "no detour" responses,
which would cause the CC-Top-AS to incorrectly include a Sub-Transit-
CC in the blocklist, leading to denial of service for legitimate
traffic.
Additionally, the source prefixes used in response messages should
not be blocked by the PI-SAV blocklist itself; otherwise, responses
may be dropped. This can be avoided by ensuring that the response
channel uses source addresses that are not in the blocklist (e.g.,
addresses from a dedicated management network).
For Standalone CC, security considerations are limited to the
correctness of the input data (BGP RIB, RPKI, SLURM). Incorrect or
incomplete data may result in a blocklist that either misses spoofed
packets (under-protection) or blocks legitimate traffic (over-
protection). Operators should validate their data sources and use
the feedback mechanism (Section 4.5) to detect and correct
information gaps.
7. IANA Considerations
This document includes no request to IANA.
8. References
8.1. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/info/rfc8416>.
Huang, et al. Expires 26 November 2026 [Page 15]
Internet-Draft PI-SAV for CC Sources May 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
[RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
Kent, "A Profile for Route Origin Authorizations (ROAs)",
RFC 9582, DOI 10.17487/RFC9582, May 2024,
<https://www.rfc-editor.org/info/rfc9582>.
[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Gap
Analysis, Problem Statement, and Requirements for Inter-
Domain SAV", Work in Progress, Internet-Draft, draft-ietf-
savnet-inter-domain-problem-statement-16, 7 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-16>.
[I-D.ietf-savnet-general-sav-capabilities]
Huang, M., Cheng, W., Li, D., Geng, N., and L. Chen,
"General Source Address Validation Capabilities", Work in
Progress, Internet-Draft, draft-ietf-savnet-general-sav-
capabilities-02, 10 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
general-sav-capabilities-02>.
[I-D.ietf-sidrops-aspa-profile]
Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley,
R., and B. Maddison, "A Profile for Autonomous System
Provider Authorization", Work in Progress, Internet-Draft,
draft-ietf-sidrops-aspa-profile-26, 19 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-26>.
Authors' Addresses
Huang, et al. Expires 26 November 2026 [Page 16]
Internet-Draft PI-SAV for CC Sources May 2026
Mingqing Huang
Zhongguancun Laboratory
Beijing
China
Email: huangmq@zgclab.edu.cn
Nan Geng
Huawei Technologies
Beijing
China
Email: gengnan@huawei.com
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Huang, et al. Expires 26 November 2026 [Page 17]