SIDROPS D. Li Internet-Draft L. Qin Intended status: Standards Track Tsinghua University Expires: 16 December 2024 L. Chen L. Liu Zhongguancun Laboratory 14 June 2024 Bicone Source Address Validation draft-li-sidrops-bicone-sav-01 Abstract 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 typically generate ingress SAV allowlist filters by using information related to customer cone. This document analyzes potential improper block problems of solely using allowlist filters. To minimize improper block, this document proposes Bicone SAV, which enhances the SAV technology by additionally using blocklist filters generated based on information related to provider cone. 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 16 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expires 16 December 2024 [Page 1] Internet-Draft Bicone SAV June 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Improper Block Problems of Solely Using An Allowlist . . . . 4 4. Goals of Bicone SAV . . . . . . . . . . . . . . . . . . . . . 5 5. Generating An Allowlist Using Information Related to Customer Cone . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Generating A Blocklist Using Information Related to Provider Cone . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Generation Procedure . . . . . . . . . . . . . . . . . . 6 6.3. Overlap Between Provider Cone and Customer Cone . . . . . 7 7. Summary of Recommendations . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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]). Li, et al. Expires 16 December 2024 [Page 2] Internet-Draft Bicone SAV June 2024 Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS by using information related to customer cone. The allowlist contains prefixes belonging to the customer's or lateral peer AS's customer cone. When adopting SAV based on the allowlist, the interface only allows data packets with 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 of using allowlist filters, and proposes Bicone SAV to minimize improper block. Bicone SAV focuses on generating and applying robust ingress SAV filters at an interface facing a customer or lateral peer AS. It allows network operators to use either an allowlist filter or a blocklist filter at an interface. The blocklist filter is generated by identifying prefixes in the provider cone. When adopting SAV based on the blocklist, the interface blocks data packets with source addresses that are covered in the blocklist. The reader is encouraged to be familiar with [RFC8704], [I-D.ietf-sidrops-aspa-profile], [RFC6482], and [I-D.ietf-sidrops-aspa-verification]. 1.1. 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. Terminology 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. Li, et al. Expires 16 December 2024 [Page 3] Internet-Draft Bicone SAV June 2024 3. Improper Block Problems of Solely Using An Allowlist The basic idea of existing advanced SAV solutions is generating an allowlist by using information related to a customer's (or lateral peer's) customer cone. Specifically, they identify prefixes in a customer's (or lateral peer's) customer cone and only accepts data packets with source addresses belonging to these prefixes on the interface facing that customer (or lateral peer). This is because data packets received from a customer or lateral peer should use source addresses belonging to prefixes in the customer's or lateral peer's customer cone 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/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) Li, et al. Expires 16 December 2024 [Page 4] Internet-Draft Bicone SAV June 2024 Figure 1: An example of limited propagation of prefixes in the customer cone 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 ASPAs and ROAs are missing, the SAV solution will still fail to discover all prefixes in a customer's or lateral peer's customer cone, leading to improper block. Overall, considering the complexity of inter-domain routing, existing SAV solutions which solely use an allowlist may fail to identify all prefixes in a customer's (or lateral peer's) customer cone. In this case, the generated allowlist may result in improper block. To minimize improper block, Bicone SAV suggests network operators to use blocklist filters in this scenario. 4. Goals of Bicone SAV Bicone SAV aims to perform more robust ingress SAV filtering at interfaces facing a customer or a lateral peer by flexibly using allowlist and blocklist filters. It has two main goals: 1. Avoiding improper block. Bicone SAV aims to avoiding block legitimate data packets received from a customer or a lateral peer. If using an allowlist at an interface may have improper block problems, Bicone SAV recommends using a blocklist at this interface. 2. Maintaining directionality. When using a blocklist at an interface facing a customer or a lateral peer, the SAV filter can block data packets using source addresses belonging to the provider cone. When using an allowlist at an interface facing a customer or a lateral peer, the SAV filter can block data packets using source addresses not belonging to the customer's or lateral peer's customer cone. 5. Generating An Allowlist Using Information Related to Customer Cone Existing SAV solutions (e.g., EFP-uRPF, BAR-SAV) can be used to generate allowlist filters at interfaces facing a customer or a lateral peer. 6. Generating A Blocklist Using Information Related to Provider Cone Li, et al. Expires 16 December 2024 [Page 5] Internet-Draft Bicone SAV June 2024 6.1. Key Idea 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. Data packets received from customers or lateral peers with source addresses in the blocklist should be blocked. Note that if an AS cannot identify all ASes in the provider cone when ASPAs are partially deployed, the generated blocklist will not include all prefixes in the provider cone. In this case, the generated blocklist can still block spoofing traffic received from customers and lateral peers with source addresses in the blocklist. Therefore, Bicone SAV provides immediate incremental benefits to early adopters. 6.2. Generation Procedure A detailed description of blocklist generation procedure is as follows: 1. Create the set of all directly connected Provider ASNs. Call it AS-set Z(1). 2. Create the set of all unique AS_PATHs in Adj-RIBs-In of all interfaces facing Providers. 3. 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. 4. Let i = N 5. Decrement i to i-1. Li, et al. Expires 16 December 2024 [Page 6] Internet-Draft Bicone SAV June 2024 6. 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. 7. If i == 1, go to Step 3. Else, go to Step 5. 8. Let k = 1. 9. Increment k to k+1. 10. 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). 11. 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. 12. 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. 13. 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. 14. 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. 6.3. Overlap Between Provider Cone and Customer Cone 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 a customer's or lateral peer's customer cone. Therefore, the allowlist and blocklist generated for the corresponding interface will both contain this prefix. To avoid improper block when using the blocklist, the blocklist must remove prefixes that are also contained in the allowlist. 7. Summary of Recommendations For an interface facing a customer or lateral peer: Li, et al. Expires 16 December 2024 [Page 7] Internet-Draft Bicone SAV June 2024 1. If the network operator makes sure the generated allowlist covers all prefixes in a customer's or lateral peer's customer cone, it is recommended to use an allowlist filter because allowlist filter has more strict directionality than blocklist filter. 2. If the network operator cannot make sure the generated allowlist covers all prefixes in a customer's or lateral peer's customer cone, it is recommended to use a blocklist filter to avoid improper block. For example, in Figure 1, it is recommended that AS4 uses an allowlist filter at the interface facing AS5 and uses a blocklist filter at the interface facing AS2. 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. 8. Security Considerations 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. 9. IANA Considerations This document has no IANA requirements. 10. References 10.1. Normative References [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, . [I-D.ietf-sidrops-aspa-profile] Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-17, 7 November 2023, . Li, et al. Expires 16 December 2024 [Page 8] Internet-Draft Bicone SAV June 2024 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [I-D.ietf-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa- verification-17, 29 February 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [I-D.ietf-savnet-intra-domain-problem-statement] Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain-problem- statement-03, 13 February 2024, . [I-D.ietf-savnet-inter-domain-problem-statement] Li, D., Wu, J., Liu, L., Huang, M., and K. Sriram, "Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-ietf-savnet-inter-domain-problem- Li, et al. Expires 16 December 2024 [Page 9] Internet-Draft Bicone SAV June 2024 statement-04, 19 March 2024, . [I-D.ietf-sidrops-bar-sav] Sriram, K., Lubashev, I., and D. Montgomery, "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR- SAV)", Work in Progress, Internet-Draft, draft-ietf- sidrops-bar-sav-03, 4 March 2024, . [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, . Authors' Addresses Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Lancheng Qin Tsinghua University Beijing China Email: qlc19@mails.tsinghua.edu.cn Li Chen Zhongguancun Laboratory Beijing China Email: lichen@zgclab.edu.cn Libin Liu Zhongguancun Laboratory Beijing China Email: liulb@zgclab.edu.cn Li, et al. Expires 16 December 2024 [Page 10]