Provider Interface SAV for Customer Cone Sources

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/.¶

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 19 April 2026.¶

Copyright Notice

Copyright (c) 2025 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

As described in [RFC3704][RFC8704][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 constitute the majority of top DDoS attack types.¶

The solutions described in this document, based on the customer cone (CC) source address information and its routing characteristics, generates 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.¶

Section 4 introduces the basic solution: PI-SAV for standalone CC. This solution focuses on how to construct a standalone CC -- a subset of CC, in which all member ASes share transit providers on the top AS of the CC, no any other alternative transit provider. Under the valley-free principle of BGP routing, the traffic between the hosts in the Standalone CC must not traverse the provider interfaces of the CC, so a PI-SAV source prefix blocklist can be generated based on this standalone CC.¶

Section 5 introduces the improved solution: PI-SAV for standalone+ CC. This solution does not simply assume alternative transit provider will cause CC traffic detour through the provider interfaces as the PI-SAV for standalone CC solution does, but to check whether there is route policy configuration or link failure causing so. If no detour exists, a standalone CC+ can be formed by adding the corresponding ASes (the sub-CC under the alternative transit provider) to the standalone CC. By doing so, a more complete PI-SAV prefix blocklist can be formed based on the standalone CC+. The mechanism for Standalone+ CC solution can also be used to enhance Standalone CC solution, working as an in-band channel to get provider information of CC-Member-AS in stead of relying on out-band RPKI ASPA or SLRUM records.¶

Note that this document mainly elaborates the basic principles and general procedures of the solutions, the details for additional information provisioning (e.g. Partial-Transit object management) or communication protocol between ASes for Standalone+ CC is not included.¶

2. Basic Solution: PI-SAV for Standalone CC

The PI-SAV for Standalone CC solution mainly focuses on solving two key problems: 1) how to construct the standalone CC by deducting the sub-transit-CC(es) from the whole CC without any omission, and 2) how to generate source prefix blocklist for the standalone CC by subtracting the prefix(es) with multi-origin AS.¶

Standalone CC construction requires the complete knowledge of the CC-Member-AS and whether each of them has alternative transit provider outside the CC. Basically, CC-Top-ASBR can get the complete list of CC member AS based on BGP local-RIBs if there is no Partial Transit implemented in the CC, that is, ASBR needs to know whether there is any Partial Transit applied in the CC to guarantee the completeness of CC member AS list. Note that, although RPKI ASPA [I-D.ietf-sidrops-aspa-profile] can cover the knowledge of partial transit, and itself can also be used to find the list of CC member AS, it is not recommended to primarily rely on RPKI ASPA for generating CC member list. 1) It will be a long run for RPKI ASPA registration getting ubiquitous, and more importantly, ASPA record themselves cannot indicate whether all ASes have registered. 2) Timeliness due to RPKI record update latency. It is normal situation that the RPKI record updates lay behind the real network changes. 3) It needs to search for all the ASPA records per customer layer, and carefully deal with the race condition between RPKI ASPA records.¶

While Standalone CC gets constructed, the initial prefix blocklist for PI-SAV can be generated based on local-RIBs. However, prefix in this list may get involved with multiple origin, that is, the same prefix may also be announced by CC outside network. Furthermore, different ASes in the CC may choose different origin AS path for a specific MOAS prefix, in this case, legitimate traffic with this source prefix may flow in the CC through provider interfaces of the CC, so the CC source prefixes with outside origin AS should be deducted from the initial blocklist. The knowledge of MOAS prefix may be covered by RPKI ROA [RFC9582] and/or RPKI ROA SLURM.¶

Based on the above discussion, the solution proposed in this document constructs the PI-SAV blocklist primarily based on local-RIBs information and additional supports from local SLURM and RPKI records. The general procedure for CC-Top-ASBR generating PI-SAV blocklist for Standalone CC listed as below:¶

1. Initial CC member ASN collection. Includes 2 parts: a) ASNs for all direct customer ASes of the CC-Top-AS. The CC-Top-ASBR should have this information in its system. b) Get partial transit deployment information (ASN of CC-Member-AS which only partial transit with upper ASes in the CC) for the target CC. SLURM based local management for partial transit information is suggested.¶

2. CC construction. Based on the initial ASNs collected above, find all CC-Member-ASes by searching the local-RIBs for which is under the initial ASN in the AS-paths. The transit relationship between member ASes must be saved for further Sub-Transit-CC construction.¶

3. Sub-Transit-CC construction. Firstly, check whether there is any alternative transit provider outside the CC for each CC-Member-AS, mark the CC-Member-AS as a CC-Sub-Transit-AS if there is. This can be done by RPKI ASPA records, and SLURM based local support for additional information is encouraged. Note, if the transit provider information is not available for any CC-Member-AS, the AS must be marked as CC-Sub-Transit-AS. Then construct Sub-Transit-CC for each CC-Sub-Transit-AS.¶

4. Standalone CC construction. Deduct all the Sub-Transit-CCes from the CC to form standalone CC.¶

5. Generating the initial prefix list for the standalone CC. Based on BGP local-RIBs, collect all prefixes initiated from the member ASes of the Standalone CC.¶

6. Final prefix blocklist generation. Check whether any prefix in the initial list get involved with multiple origin AS (MOAS), that is, the prefix is originated not only by the AS(es) inside the CC but also by the AS(es) outside the CC, deduct the prefix with MOAS from the initial list. MOAS prefix indentification can be based on RPKI ROA and/or local ROA SLURM records. Local-RIBs-in can also be used to indentify whether there is any external origin AS for a CC source prefix. Note, router implementation in current practice may not save all local-RIBs-in records, so it needs further consideration if we want find all CC prefixes with external origin AS.¶

Note: the prefix blocklist must avoid improper block while generating the prefix list, which means while a prefix is not sure and hard to determine whether it should be included in the blocklist, just do not include it. The hidden prefix described in [I-D.ietf-savnet-inter-domain-problem-statement] (No-Export and DSR etc.) might be the cases.¶

3. Improved Solution: PI-SAV for Standalone+ CC

Although alternative transit link may cause the traffic between CC member ASes detouring through provider interfaces of the CC, however, the detour path, which normally is longer path compared to inner CC path, only happens while specific routing policy configuration or internal transit path failure making so. That is, traffic detour through provider interface for CC communication is not the normal case.¶

On the basis of the previous PI-SAV for standalone CC solution, the initial goal of the PI-SAV for standalone+ CC solution is to identify as many prefixes as possible for the PI-SAV blocklist where the Sub-Transit-CC they belongs actually has no detour happen. This solution will be more meaningful if standalone CC can only count a small portion of whole CC.¶

Another benefit of the improved solution is that it can enhance PI-SAV for Standalone CC solution by providing additional information support via in-band channel (communication between CC member ASes), rather than heavily relying on out-band source (RPKI and/or local SLURM), where the former can provide more accurate, complete, and timely information support.¶

There are two modes described in this document:¶

1) Conservative Mode: This mode starts from the standalone CC, forming the standalone+ CC by adding a sub-transit-CC back when it is confirmed that no detour happened for this sub-transit-CC.¶

2) Aggressive Mode: This mode starts from the whole CC, forming the standalone+ CC by pruning a sub-transit-CC out when it is confirmed that detour happened for this Sub-Transit-CC. The aggressive mode requires all CC-Sub-Transit-ASes support cooperation with the CC-Top-AS based on the PI-SAV for standalone+ CC solution.¶

    -- The mode of PI-SAV for standalone+ CC.

    -- CC-Top-ASBR information, including the router identification and information about how it can be connected for member AS to response.

    -- The CC-Member-AS and CC-sub-transit-AS information.

4. Considerations

This document focuses on the general solution architecture for PI-SAV for CC, including the communication mechanism between CC-Top-AS and CC-sub-Transit-AS for PI-SAV for Standalone+ CC solution, the details of protocol design is not included. Some considerations:¶

1) Deployment Considerations.¶

The deployment position for the solutions is suggested for a region center AS, rather than a top/high tier AS with complex connection across regions. This means the ASes in the CC are normally/mainly connected to outside internet through the region top AS, and it would be easier and more efficient for them to implement comprehensive PI-SAV for CC solution.¶

Meanwhile, the solution should allow the incremental deployment in this region/the CC, which means some member ASes may not support the solution or some information (e.g. ASPA records for some ASes) may not be available. However, 1) The partial transit information must be fully covered to avoid the hidden AS in the CC. 2) MOAS prefixes must be fully identified to avoid related prefix improper block.¶

2) Security Considerations.¶

This is mainly related to the communication mechanism between ASes in the Standalone+ scheme. Generally (not base on the detailed protocol design), the communication mechanism must be equipped with the reliability and security features inherent in conventional transport protocols. Additionally, to avoid MITM (Man-in-the-middle) attacks, the protocol message can be encrypted and authenticated based on router-keys.¶

Note: the source prefix of response message should not be in the blocklist in case the message needs to detour back through provider interfaces, this can be done at early normal situation.¶

5. IANA Considerations

This document includes no request to IANA.¶

6. References

Authors' Addresses