Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)

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 14 September 2023.¶

Copyright Notice

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

2. Same Procedure Applies to Customers and Lateral Peers

The same procedure applies for the construction of a permissible ingress SAV filter for a customer or lateral peer interface, because the data packets received from a customer or lateral peer should have source addresses belonging only to the prefixes in the customer cone (CC) of said customer or lateral peer. The focus, therefore, is only on the CC of the neighbor in each case. Note that the CC includes the AS belonging to the customer or lateral peer.¶

3. SAV Using ASPA and ROA (Procedure X)

The procedure (called Procedure X) described in this section is for future scenarios when ASPA and ROA adoption is ubiquitous. In that scenario, robust SAV filters can be generated from the RPKI information (ASPA and ROA data) alone. The procedure is applicable for ingress SAV filter design for customer and lateral peer interfaces. An ISP may use Procedure X on a customer (or lateral peer) interface if it expects full adoption of ROAs and ASPAs in the CC of the neighbor.¶

A description of Procedure X (one that makes use of only ASPA and ROA data):¶

• Step A: Compute the set of ASNs in the Customer's or Lateral Peer's customer cone using ASPA data.¶
• Step B: Compute from ROA data the set of prefixes authorized to be announced by the ASNs found in Step A. Keep only the unique prefixes. This set is the permissible prefix list for SAV for the interface in consideration.¶

A detailed description of Procedure X is as follows:¶

1. Let the Customer or Lateral Peer ASN be denoted as AS-k.¶
2. Let i = 1. Initialize: AS-set S(1) = {AS-k}.¶
3. Increment i to i+1.¶
4. Create AS-set S(i) of all ASNs whose ASPA data declares at least one ASN in AS-set S(i-1) as a Provider.¶
5. If AS-set S(i) is null, then set i_max = i - 1 and go to Step 6. Else, go to Step 3.¶
6. Form the union of the sets, S(i), i = 1, 2, ..., i_max, and name this union as AS-set A.¶
7. Select all ROAs in which the authorized origin ASN is equal to any ASN in AS-set A. Form the union of the sets of prefixes listed in the selected ROAs. Name this union set of prefixes as P-set.¶
8. Apply P-set as the list of permissible prefixes for SAV.¶

4. SAV using BGP UPDATE Messages, ASPA, and ROA (BAR-SAV)

SAV using BGP UPDATE Messages, ASPA, ROA (BAR-SAV) as well as ACLs is described in this section and is meant for the period when there is a partial deployment of ROAs and ASPAs. To compensate for incomplete RPKI information, BAR-SAV augments ASPA data with BGP UPDATE AS_PATH data (and ASN ACLs) for discovering CC ASes, and it augments ROA data with BGP UPDATE data (and Prefix ACLs) for discovering all prefixes associated with ASes in the CC. The details of this procedure are described below.¶

BAR-SAV additionally incorporates a refined version of Algorithm A of EFP-uRPF (Section 3.1 of [RFC8704]). Algorithm A in [RFC8704] picked only the originating ASes from AS_PATHs received on the customer or lateral peer interface in consideration and included them for SAV filter computation. The variant of Algorithm A in [RFC8704] used here includes all ASes in the AS_PATHs for the SAV filter computation. Unless there is a route leak [RFC7908], each AS is a customer of the AS added next in AS_PATHs of BGP UPDATE messages received from a customer or lateral peer. Further customer-provider AS relations within the CC are discovered by examining all unique ASes in the AS_PATHs in BGP UPDATEs received on all interfaces (from transit providers, customers, lateral peers, and IBGP peers). This is described in the step-by-step procedure later in this section.¶

Note that if a multi-homed AS is present in an above-mentioned AS_PATH and did not originate any prefix in the CC in consideration but originated a prefix into an overlapping neighboring CC, then the AS and prefix will still be detected and included in the design of the SAV filter. This improves the accuracy of the SAV filter in the BAR-SAV method in comparison to Algorithm A in [RFC8704].¶

One should not compute a customer cone by separately processing ASPA data and AS_PATH data and then merging the two sets of ASes at the end. Doing so is likely to miss ASes from the customer cone. Instead, both ASPAs and AS_PATHs should be used to iteratively expand the discovered customer cone. When new ASes are discovered, both ASPA and AS_PATH data should be used to discover customers of those ASes. This process is repeated for newly discovered customer ASes until there are no new ASes to be found.¶

As a measure of security, validation of the AS_PATH data in Adj-RIBs-In [RFC4271] SHOULD be performed using the procedures in [I-D.ietf-sidrops-aspa-verification] and any Invalid AS_PATHs must be excluded from inputs to the BAR-SAV procedure. This ensures that BGP UPDATEs containing route leaks are not considered for BAR-SAV filter design. Please see additional discussion about route leaks in Section 9.¶

As a further measure of security, validation of BGP routes in Adj-RIBs-In MUST be performed by applying RPKI-ROV [RFC6811] and any Invalid routes must be excluded from inputs to the BAR-SAV procedure. Please see additional discussion about prefix/route filtering in Section 9.¶

A detailed description of the BAR-SAV procedure is as follows:¶

1. Let the Customer or Lateral Peer ASN be denoted as AS-k.¶
2. Let i = 1. Initialize: AS-set Z(1) = {AS-k}.¶
3. Extend AS-set Z(1) to include ASNs from any ASN ACL configured for this interface.¶
4. Increment i to i+1.¶
5. Create AS-set A(i) of all ASNs whose ASPA data declares at least one ASN in AS-set Z(i-1) as a Provider.¶
6. Create AS-set B(i) of all customer ASNs each of which is a customer of at least one ASN in AS-set Z(i-1) according to unique AS_PATHs in Adj-RIBs-In of all interfaces at the BGP speaker computing the SAV filter.¶
7. Form the union of AS-sets A(i) and B(i) and call it AS-set C. From AS-set C, remove any ASNs that are present in Z(j), for j=1 to j=(i-1). Call the resulting set Z(i).¶
8. If AS-set Z(i) is null, then set i_max = i - 1 and go to Step 9. Else, go to Step 4.¶
9. Form the union of the AS-sets, Z(i), i = 1, 2, ..., i_max, and name this union as AS-set D.¶
10. Select all ROAs in which the authorized origin ASN is in AS-set D. Form the union of the sets of prefixes listed in the selected ROAs. Name this union set of prefixes as Prefix-set P1.¶
11. Using the routes in Adj-RIBs-In of all interfaces, create a list of all prefixes originated by any ASN in AS-set D. Name this set of prefixes as Prefix-set P2.¶
12. Form the union of Prefix-set P1, Prefix-set P2, and any Prefix ACL configured for this interface. Apply this union set as the list of permissible prefixes for SAV.¶

5. Operational Recommendations

Network operators SHOULD implement the BAR-SAV method (Section 4) for computing the permissible ingress prefix list for SAV on interfaces facing customers and lateral peers. BAR-SAV offers immediate incremental benefits to early adopters.¶

The operational recommendations provided in Section 3.2 of [RFC8704] are applicable and helpful for BAR-SAV (Section 4). Since Procedure X (Section 3) and the BAR-SAV procedure (Section 4) benefit from the registration of ROAs, network operators are RECOMMENDED to register ROAs and enable RPKI-ROV in their ASes. When ASPA registration becomes available, network operators are also RECOMMENDED to register ASPAs at that time.¶

The registration of ROAs and ASPAs helps with the detection and inclusion of otherwise hidden prefixes in the permissible list for SAV. As mentioned earlier, prefixes hidden in other SAV techniques often arise from the use of multi-homing in conjunction with limited propagation of prefixes in a given CC (for example, by attaching NO_EXPORT to all prefixes announced from a customer AS to a transit provider AS). In these situations, the registration of ASPAs and ROAs helps improve the accuracy of SAV.¶

                 +----------+   P3{AS5 AS3}  +------------+
                 |    AS4   |<---------------|     AS5    |
                 +----------+      (P2P)     +------------+
                     /\   /\                        /\
                     /     \                         \
             P1{AS1}/       \P2{AS2}                  \P3{AS3}
              (C2P)/         \(C2P)                    \(C2P)
                  /           \                         \
           +----------+    +----------+           +----------+
           |  AS1 (P1)|    | AS2 (P2) |           | AS3 (P3) |
           +-----+----+    +----+-----+           +-----+----+
                 +              +                       +
               User       Edge Server (DSR)      Anycast Server

          Consider AS4 generating SAV list for interface to AS2:
          CDN's ROAs: {P3, AS3}, {P3, AS2}, {P2, AS2}
          AS2 should not/does not announce P3
          With the SAV methods in this document,
             AS4 correctly includes P2 and P3 in the SAV list

6. Operations and Management Considerations

This section highlights some important operations and management considerations and was motivated in part to address the comments received from the SIDROPS working group members.¶

7. Provider Interfaces

For most networks, "loose uRPF" SAV mode described in [RFC3704] and [RFC8704] is the current best practice for provider interfaces to ensure no improper block. It may be possible to use BGP UPDATE as well as RPKI ROA and ASPA data to compute a list of prefixes that originate exclusively within the customer cone and should only be received by the AS on customer interfaces. A set of such prefixes can be used in conjuction with "loose uRPF" SAV mode as a blocklist on provider interfaces.¶

8. IANA Considerations

This document includes no request to IANA.¶

9. Security Considerations

The security considerations described in [RFC8704], [RFC6811], [I-D.ietf-sidrops-aspa-profile], and [I-D.ietf-sidrops-aspa-verification] also apply to this document.¶

The security and robustness of BAR-SAV are strengthened by supporting mechanisms for detecting and dropping BGP routes that are misoriginations or leaks. Section 4 stated the requirement of validating BGP route origins using RPKI-ROV [RFC6811]. It further helps if route origin validation using trusted IRR route objects and prefix filtering are also deployed (see [RFC7454] [NIST-800-189]). It is also advised that one or more of the available methods to prevent, detect, and mitigate route leaks are deployed (e.g., [RFC9234] [I-D.ietf-grow-route-leak-detection-mitigation] [I-D.ietf-sidrops-aspa-verification] [sriram1]).¶

Acknowledgements

The authors would like to thank Oliver Borchert, Job Snijders, Ben Maddison, Geoff Huston, Dan Li, and many other members of the SIDROPS and SAVNET working groups for comments and discussion.¶

Authors' Addresses