Provider Interface SAV for Customer Cone Sources

Introduction As described in , 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 , 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.

Terminology Customer Cone (CC): a set of ASes that are direct/indirect customer ASes of a given AS, including the customer AS's customer ASes and so on, till the stub ASes. CC-Top-AS: the top AS for the customer cone (i.e. the given AS mentioned above), which means all other ASes in the CC are its direct/indirect customer ASes. CC-Top-ASBR: ASBR (AS Boarder 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. 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, the 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: a subset of CC, all ASes within a Standalone CC share same transit provider(s) on the CC-Top-AS, i.e. the member AS of a Standalone CC has no alternative transit provider outside the CC, all Sub-Transit-CCes in the CC must be excluded. Based on the valley-free principle of BGP routing, the traffic flow between the Standalone CC hosts will not go through the CC-Top-AS's provider interfaces. Partial Transit: a special transit provider service between two eBGP neighbors, which is rarely deployed in the wild. When an AS (AS-a) receives the 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. Standalone+ CC: a superset of a Standalone CC that includes the sub-transit-CC(s) which has no detour happened for the CC traffic, i.e., 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 route policy configuration or transit link failure.

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.

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 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 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:

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.
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.
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.
Standalone CC construction. Deduct all the Sub-Transit-CCes from the CC to form standalone CC.
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.
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 (No-Export and DSR etc.) might be the cases.

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.

Conservative Mode The general procedures for PI-SAV for Standalone+ CC conservative mode: 1) CC-Top-ASBR enables PI-SAV for standalone+ CC conservative mode. The system sets the standalone CC as the initial standalone+ CC. And then it sends a notification message to all CC-Member-ASes. The information in the message includes: After the notification message, update message must be sent if relevant information changes. 2) CC-member-AS receives the notification/update message. Based on the BGP local-RIBs, CC-Member-AS verifies whether it has preferred an external transit provider for the BGP updates originated from CC member ASes. Then send response message back to CC-Top-ASBR. Since then, response update message must be sent while related route preferences change (due to routing policy or transit link status change etc.). 3) CC-Top-ASBR receives the response message. It will add the corresponding CC-sub-transit-AS and its sub-transit-CCs into the standalone+ CC while the message shows no detour through alternative provider. 4) CC-Top-ASBR generates blocklist for Standalone+ CC like standalone CC does, including deduction of MOAS prefixes. Note that, in conservative mode, in case no response message is received from a sub-transit-AS, it will be assuming that there is external detour paths exist for it. Based on the communication mechanism between CC-Top-AS and CC-Member-AS, the procedure can also be used for enhancing PI-SAV for Standalone CC solution. It can provide more accurate, complete and real-time feedback for additional information required, for example, whether a member AS has partial transit implemented, has external provider existence, or a CC prefix with external origin AS, rather than just relying on out-band pre-registration (RPKI or local SLURM).

Aggressive Mode The general procedures for PI-SAV for Standalone+ CC aggressive mode: 1) When the CC-Top-ASBR enables PI-SAV for standalone+ CC aggressive mode, the system sets the whole CC as the initial standalone+ CC. Then it sends a notification message to all CC-Member-ASes, the information in the message is similar with conservative mode but with aggressive mode identifier. After that, update message need to be sent if relevant information changes. 2) The CC-Member-AS receives the notification/update message, based on the BGP Local-RIBs, verifying whether it has preferred an external transit provider for the BGP updates originated from CC member ASes. Then send response message back to CC-Top-ASBR. Since then, response update message must be sent while related route preference change (due to routing policy or transit link status change etc.). 3) After CC-Top-ASBR receives the response message, it will prune the corresponding CC-sub-transit-AS and its sub-standalone-CCs from the initial standalone+ CC while the message shows detour through alternative provider. 4) Only after CC-Top-AS gets response from all CC-sub-transit-ASes, generates blocklist for Standalone+ CC like standalone CC does, including deduction of MOAS prefixes. Same as the previous conservative mode, this mechanism can also be used for PI-SAV for Standalone CC solution enhancement.

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.

IANA Considerations This document includes no request to IANA.