| Internet-Draft | Bicone SAV | July 2024 |
| Li, et al. | Expires 29 January 2025 | [Page] |
The primary design goal of source address validation (SAV) is avoiding improper block (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions ([RFC8704] and [I-D.ietf-sidrops-bar-sav]) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS. This document analyzes potential improper block problems when using the allowlist. To enhance the SAV robustness and avoid improper block, this document provides an additional option for network operators, i.e., generating a blocklist filter by using BGP updates, ROAs, and ASPAs related to the provider cone. Network operators can flexibly use the allowlist or blocklist on different interfaces according to their requirements and actual conditions.¶
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 29 January 2025.¶
Copyright (c) 2024 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 is one of the most serious security threats to today's Internet. It serves as a main attack vector for large-scale Distributed Denial of Service (DDoS) attacks and is commonly used in reflective DDoS attacks. To mitigate source address spoofing, many source address validation (SAV) solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704] [RFC8704]) have been proposed. The primary design goal of SAV solutions is avoiding improper block (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). However, previous SAV solutions cannot meet the design goal due to technical limitations (see [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-inter-domain-problem-statement]).¶
Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704] and BAR-SAV [I-D.ietf-sidrops-bar-sav]) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS by using information related to the customer cone of that AS. The allowlist must contain all prefixes belonging to the corresponding customer cone. When adopting SAV based on the allowlist, the interface only allows incoming data packets using source addresses that are covered in the allowlist. However, using an allowlist may cause legitimate traffic to be blocked if the allowlist fails to cover all prefixes in the customer cone.¶
This document analyzes potential improper block problems when using the allowlist. To enhance the SAV robustness and avoid improper block, this document provides an additional option for network operators, i.e., generating a blocklist filter by using BGP updates, ROAs, and ASPAs related to the provider cone. The blocklist should contain as many prefixes belonging to the provider cone as possible. When adopting SAV based on the blocklist, the interface blocks incoming data packets using source addresses that are covered in the blocklist. Network operators can flexibly use the allowlist or blocklist on different interfaces according to their requirements and actual conditions.¶
The reader is encouraged to be familiar with [RFC8704], [I-D.ietf-sidrops-aspa-profile], [RFC6482], and [I-D.ietf-sidrops-aspa-verification].¶
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.¶
Provider Cone: the set of ASes an AS can reach by using only customer-to-provider links.¶
The basic idea of existing advanced SAV solutions is generating an allowlist by using information related to the customer cone of a customer or lateral peer AS. Specifically, they identify prefixes in the customer cone and only accepts data packets using source addresses belonging to these prefixes on the interface facing that customer or lateral peer AS. This is because data packets received from a customer or lateral peer AS should use source addresses belonging to the customer cone of that AS unless there is a route leak [RFC7908].¶
EFP-uRPF (BCP84 [RFC8704]) generates allowlists by using BGP UPDATE messages related to the customer cone. However, if a multi-homed AS in the customer cone limits the propagation of its prefixes, EFP-uRPF may miss these prefixes in the allowlist, resulting in improper block. Section 3.3 of [RFC8704] has given such an example of limited propagation of prefixes where a multi-homed customer AS attaches NO_EXPORT to all prefixes announced to one transit provider. Figure 1 illustrates a similar scenario of limited propagation of prefixes in the customer cone of AS4. Since AS1 attaches NO_EXPORT to routes for P1 and P2 announced to AS2, routes for P1 and P2 are not propagated on the AS2-AS4 interface. Because AS4 never receives routes for P1 and P2 from its customer AS2, both EFP-uRPF Algorithm A and Algorithm B at AS4 will block legitimate data packets received on AS4-AS2 interface with source addresses in P1 or P2.¶
P1[AS5 AS3 AS1]
P2[AS5 AS3 AS1]
+---------+ (P2P/C2P) +---------+
| 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)
Some more recent SAV solutions (e.g., BAR-SAV [I-D.ietf-sidrops-bar-sav]) additionally use Autonomous System Provider Authorization (ASPA) [I-D.ietf-sidrops-aspa-profile] and Route Origin Authorization (ROA) [RFC6482] to generate a more robust allowlist. However, since registering ASPAs and ROAs is optional for network operators, ASPAs and ROAs will be partially deployed for a long time. When some ASes in the customer cone do not register ASPAs or ROAs, the SAV solution will still fail to discover all prefixes in the customer cone. If the allowlist is not complete, it will improperly block data packets using legitimate source addresses.¶
Overall, considering the complexity of inter-domain routing, existing SAV solutions which solely use allowlist filters may fail to identify all prefixes of the customer cone (e.g., when some prefixes are limited propagated in the customer cone). In this case, the incomplete allowlist will result in improper block.¶
Bicone SAV aims to achieve more robust ingress SAV filtering on interfaces facing a customer or lateral peer AS by flexibly using allowlist or blocklist filters. It has two main goals:¶
Avoiding improper block. Bicone SAV aims to avoid block legitimate data packets received from a customer or lateral peer AS. As described in Section 3, if the allowlist is incomplete, it will improperly block legitimate data packets. In this case, it is recommended to use a blocklist to avoid improper block.¶
Maintaining directionality. When using an allowlist, the SAV filter can block data packets using source addresses not belonging to the customer cone of the customer or lateral peer AS. When using a blocklist, the SAV filter can block data packets using source addresses belonging to the provider cone. It cannot prevent an AS in the customer cone of a customer or lateral peer AS from using source addresses of the customer cone of another customer or lateral peer AS. Therefore, the allowlist filter has stricter directionality than the blocklist filter.¶
Overall, the blocklist performs better in achieving the first goal while the allowlist performs better in achieving the second goal. In the following, this document introduces existing allowlist-based SAV solutions and the design of a new blocklist-based SAV solution.¶
Existing SAV solutions (e.g., EFP-uRPF [RFC8704], BAR-SAV [I-D.ietf-sidrops-bar-sav]) can be used to generate an allowlist on interfaces facing a customer or lateral peer AS by using BGP updates, ROAs, and ASPAs related to the corresponding customer cone.¶
This section introduces a blocklist-based SAV solution that generates blocklist filters on interfaces facing a customer or lateral peer AS by using BGP updates, ROAs, and ASPAs related to the provider cone.¶
The provider cone of an AS is defined as the set of ASes an AS can reach by using only customer-to-provider links. Considering prefixes associated with ASes in the provider cone should not be used as source addresses in data packets received from any customer or lateral peer AS unless there is a route leak [RFC7908]. The blocklist should contain prefixes belonging to the provider cone.¶
To generate a blocklist, an AS first identifies ASes in its provider cone by using ASPAs and AS-PATH in BGP UPDATE messages. Then, it discovers prefixes belonging to these ASes in provider cone and includes those prefixes in the blocklist. When using the blocklist on an interface facing a customer or lateral peer AS, data packets received from that interface using source addresses in the blocklist should be blocked.¶
A detailed description of 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, 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 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. Call it Prefix-set P1.¶
Using the routes in Adj-RIBs-In of all interfaces facing Providers, create a set of prefixes originated by any ASN in AS-set Z(k_max). Call it Prefix-set P2.¶
Form the union of Prefix-set P1 and Prefix-set P2. Apply this union set as a blocklist on an interface facing a customer or lateral peer AS.¶
In some scenarios (e.g., the CDN and DSR scenario described in [I-D.ietf-savnet-inter-domain-problem-statement] and [I-D.ietf-sidrops-bar-sav]), a prefix may exist both in the provider cone and the customer cone. To avoid improper block, the blocklist must remove prefixes that also belong to the customer cone. These prefixes can be identified by computing the overlap between blocklist and allowlist.¶
Note that it is difficult for an AS to identify all ASes in its provider cone when some ASes in the provider cone do not register ASPAs. Therefore, the generated blocklist will not include all prefixes in the provider cone. When the blocklist is incomplete, the blocklist will not improperly block legitimate data packets and will still block spoofing data packets using source addresses in the blocklist. It provides immediate incremental benefits to adopters.¶
Network operators are advised to flexibly use either allowlist or blocklist on interfaces facing different customer or lateral peer ASes according to their requirements and actual conditions.¶
The primary goal of SAV is to avoid improper block while maintaining directionality. Avoiding improper block is more important because discarding legitimate traffic will cause serious traffic interruption. On the basis of avoiding improper block, the less improper admits of SAV, the better.¶
If the allowlist on an interface is complete, it will have no improper block and no improper admit. But if the allowlist is incomplete due to hidden prefixes (e.g., prefixes P1 and P2 in Figure 1) in the customer cone and lack of necessary ASPAs, the allowlist will have improper block, thus failing to meet the goal. For a blocklist, it will not improperly block legitimate data packets whether the blocklist is complete or not. In terms of improper admit, the blocklist has much less improper admits than loose uRPF and has more improper admits than the allowlist.¶
Therefore, if the allowlist on an interface is complete, network operators are advised to use the allowlist. Otherwise, network operators are advised to use the blocklist. For small ISPs with a smaller customer cone size, it is easier to determine whether an allowlist is complete because there are fewer ASes in the customer cone and the routing is relative simple. For example, they can ask a customer or lateral peer AS whether all ASes in its customer cone have deployed ASPAs. But for large ISPs with a larger customer cone size, it is challenging. If network operators cannot determine the integrity of the allowlist, the blocklist is recommended to avoid possible improper block.¶
Additional memory (i.e., ternary content-addressable memory (TCAM)) is required to store the allowlist or blocklist in line cards. Network operators need to take storage overhead into consideration when deploying allowlists or blocklists. Generally, a small ISP will generate a smaller allowlist and a larger blocklist, while a large ISP will generate a larger allowlist and a smaller blocklist. A possible way to save memory is to store the original list in the control plane, with only the aggregated list stored in memory. For example, if the original list contains prefixes P1 and P2 and prefix P1 is a less-specific prefix of prefix P2, then only prefix P1 is stored in memory.¶
For an interface facing a customer or lateral peer AS:¶
If the network operator can determine that the allowlist covers all prefixes of the facing customer cone, it is recommended to use an allowlist on the interface because the complete allowlist has neither improper block nor improper admit. When the customer cone size is relatively small, it would be easier for the network operator to determine whether the allowlist is complete, and the allowlist size should be relatively small as well.¶
If the network operator cannot determine the integrity of the allowlist, it is recommended to use a blocklist filter to avoid improper block. In addition, given the storage overhead, the blocklist should be more appropriate than the allowlist on interfaces facing a very large customer cone.¶
For example, in Figure 1, it is recommended that AS4 uses the blocklist filter at AS4-AS2 interface, since the use of the allowlist filter here may have improper block problems. If AS4 can ensure that the use of allowlist filter at AS4-AS5 interface will not cause improper block, then it is recommended to use allowlist filter at AS4-AS5 interface. In this way, SAV at AS4 can avoid improper block while maintaining directionality. For data packets received from AS5, SAV at AS4 will block data packets using source addresses not belonging to AS1, AS3, and AS5. For data packets received from AS2, SAV at AS4 will block data packets using source addresses belonging to the provider cone of AS4.¶
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 applies to this document. Users should be aware of the potential risks of using ASPAs and ROAs to generate SAV filters, such as misconfiguration and update delay of RPKI repository.¶
This document has no IANA requirements.¶
The authors would like to thank Ben Maddison, Kotikalapudi Sriram, Nan Geng, Aijun Wang, Shengnan Yue, Siyuan Teng, and many other members of the SIDROPS and SAVNET working groups for comments and discussion.¶