Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification

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 April 2025.¶

Copyright Notice

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

Table of Contents

1. Introduction

Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer (subject) AS [I-D.ietf-sidrops-aspa-profile]. While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers (see Appendix B and Section 9 of [I-D.ietf-sidrops-aspa-verification]). This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. The Cryptographic Message Syntax (CMS) protected content type for the RPKI ASRA object is defined in [I-D.geng-sidrops-asra-profile]. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers.¶

ASPA already has the capability of detecting forged-origin or forged-path-segment hijacks (Section 2) when a verifying AS receives a BGP Update from a customer or lateral peer. ASRA adds the capability of detecting the same when a verifying AS receives a BGP Update from a provider. A forged-origin or forged-path-segment hijack involves a fake link (i.e., forged AS peering). The ASRA algorithm operates in conjunction with ASPA in such a way that it fully preserves the route leak detection capabilities of ASPA while adding the fake link detection capability.¶

Incremental benefit is accrued by early adopters. An AS that deploys ASPA and ASRA prevents an offending AS from faking a link to it if the receiving/verifying AS also deploys ASPA and ASRA. The fake link will be detected by the receiving AS even if no other AS in the received AS path has adopted ASPA or ASRA.¶

The reader is expected to be familiar with the following related documents: [I-D.ietf-sidrops-aspa-profile], [I-D.ietf-sidrops-aspa-verification], [I-D.ietf-sidrops-8210bis].¶

2. AS Path Security Problems Addressed by ASRA

            +-------+      +-------+  path{5,4,3,2,1}
            | AS(4) |------| AS(5) |--------------
            +-------+      +-------+              \
    path{3,2,1}/                \                  \ (C2P)
              /(C2P)             \                  \
      +-------+                   \              +-------+
      | AS(3) |    path{5,4,3,2,1} \             | AS(8) |
      +-------+               (C2P) \            +-------+
path{2,1} |                          \               |
    (C2P) |                           \              |
      +-------+    (Fake link)     +-------+         |path{8,5,4,
      | AS(2) |********************| AS(6) |         |    3,2,1}
      +-------+                    +-------+         | (C2P)
  path{1} |                            |path{6,2,1}  |
    (C2P) |                       (C2P)|(shortened)  |
      +-------+                    +-------+         /
      | AS(1) |                    | AS(7) |--------/
      +-------+                    +-------+
          | (Origin)            (Validating AS)
          P

            +-------+                                 +-------+
            | AS(3) |---------------------------------| AS(4) |
            +-------+                                 +-------+
      path{2,1}/                                             |
              /(C2P)                            path{4,3,2,1}|
      +-------+                        +-------+       (C2P) |
      | AS(2) |                        | AS(7) |             |
      +-------+                        +-------+             |
  path{1} |                     path{6,1}/    \path{7,6,1}   /
    (C2P) |                       (C2P) /      \(C2P)       /
      +-------+  (Fake link)     +-------+      +-------+  /
      | AS(1) |******************| AS(6) |      | AS(5) |_/
      +-------+                  +-------+      +-------+
          | (Origin)                          (Validating AS)
          P

3. ASRA Registration Recommendations

The term "Compliant AS" or "compliant BGP router" in this document refers to one that is compliant with the specifications in this document. A compliant AS that has a valid ASRA record MUST also have a valid ASPA record. A valid ASRA record(s) for a signer (subject) AS that does not have a valid ASPA record MUST be ignored (considered unusable) for AS path verification purposes.¶

There are three subcategories of ASRAs defined: ASRA1, ASRA2, and ASRA3 [I-D.geng-sidrops-asra-profile]. They are distinguished by a subcategory field by setting its value to 1, 2, or 3, respectively. ASRA1 and ASRA2 are used to register the lists of customers and lateral peers, respectively. Alternatively, if the subject AS does not wish to separately disclose customers and lateral peers, it MAY choose to register an ASRA3 to register the combined list of customers and lateral peers. An ASRA-compliant AS MUST either register ASRA3 alone or register both ASRA1 and ASRA2. To signal that there are no neighbors to report in a subcategory, AS 0 MUST be included in the corresponding ASRA subcategory in the payload field.¶

If it is found that an AS has X.509 valid ASRA3 and simultaneously has X.509 valid ASRA1 and/or ASRA2, then only the ASRA3 MUST be considered for AS path verification and the ASRA subcategories ASRA1 and ASRA2 MUST be ignored.¶

It is highly RECOMMENDED that an AS (compliant signer AS) register and maintain either a single ASRA3 object or a single object of each subcategory ASRA1 and ASRA2. Such a practice helps prevent race conditions during ASRA updates. If multiple X.509 valid ASRAs of a subcategory exist for given subject AS, the ASes listed in all such ASRAs will be combined (by the relying party) into one list of neighbors of the subcategory in consideration. This combined list will be used for AS path verification purposes.¶

All neighbors that are customers or lateral peers of the signer AS MUST be included in an ASRA(s) of an appropriate subcategory following above-mentioned recommendations.¶

A pair of compliant ASes in a mutual transit relationship are required to include each other in their respective ASPA (per [I-D.ietf-sidrops-aspa-verification]). They MUST NOT further include each other in ASRA1, ASRA2, or ASRA3. A compliant AS that has a complex relationship with a neighbor AS where one of the relationships is Provider is required to include the other AS in its ASPA (per [I-D.ietf-sidrops-aspa-verification]). The AS MUST NOT further include the other AS in ASRA1, ASRA2, or ASRA3. A compliant AS that has a complex relationship with a neighbor AS where none of the relationships are Provider implies that its relationships with the neighbor AS are customer and lateral peer. In such a case, the AS MUST include the neighbor AS in its ASRA3 if doing ASRA3, otherwise in its ASRA1 as well as ASRA2.¶

The Route Server (RS) to RS-client relationship is similar to the provider-to-customer relationship. So, a compliant non-transparent RS AS MUST either (1) list all its RS-clients as customers in ASRA3, or (2) list all its RS-clients as customers in ASRA1 and register an ASRA2 with only AS 0 listed in the set of lateral peers.¶

4. Algorithms for Enhancement of AS Path Verification Using ASRA

In this section, two algorithms are described which enhance AS path verification by augmenting ASPA-based verification [I-D.ietf-sidrops-aspa-verification] with ASRA data. The basic principles behind each algorithm are explained. (The intention is that the SIDROPS WG discussions will help decide which algorithm to select.)¶

Let the sequence {AS(N), AS(N-1),..., AS(2), AS(1)} represent the AS_PATH in terms of unique ASNs, where AS(1) is the origin AS and AS(N) is the most recently added AS and neighbor of the receiving/verifying AS. The terms AS path and AS_PATH are interchangeably used in this document. N is the AS path length in unique ASes. Let AS(N+1) represent the receiving AS that is verifying the entire received AS path. For a given AS hop, say AS(i) to AS(i+1), AS(i) is the sender and AS(i+1) is the receiver. For each such AS hop in the AS path, the algorithms seek to check if the hop is a fake link, i.e., AS(i+1) forging a connection to AS(i).¶

In the descriptions that follow, a valid ASPA or ASRA is one that is X.509 valid.¶

    - If AS(i) has valid ASPA(s) and they do not include
      AS(i+1) as a Provider,
    - AND if AS(i) has valid ASRA(s) and they do not include
      AS(i+1) as a customer or lateral peer,
    - AND {EITHER AS(i+1) has no valid ASPA OR {AS(i+1) has
      valid ASPA(s) and they do not include AS(i) as a Provider},
    - then set Fake-Link(AS(i), AS(i+1)) = Detected,
    - Else, set Fake-Link(AS(i), AS(i+1)) = Not Detected.

          L = N - min_down_ramp + 1       K = min_up_ramp

                    AS(L) ............. AS(K)
                     /                     \
                 AS(L+1)                  AS(K-1)
                    .                       .
                   .                         .
    (down-ramp)   .                           .  (up-ramp)
                 .                             .
                .                               .
              AS(N-1)                          AS(2)
                /                                \
             AS(N)                               AS(1)
              /                                (Origin AS)
    Receiving & verifying AS
           (customer)

        Each ramp has consecutive ASPA-attested
        customer-to-provider hops in the bottom-to-top direction

    1. If the outcome is Invalid, it remains unchanged
       and the procedure halts.
    2. Else, if min_up_ramp = N or {min_up_ramp + min_down_ramp} > N,
       then the outcome remains unchanged (Valid)and the procedure halts.
    3. Else, let i = min_up_ramp.
    4. If Fake-Link(AS(i), AS(i+1)) = Detected, then change the outcome
       to Invalid and the procedure halts.
    5. Else, if i = N - min_down_ramp, then the procedure halts
      (outcome remains unchanged).
    6. Else, increment i to i+1. Go to Step #4.

    - If AS(i) has valid ASPA(s) and they do not include AS(i+1)
      as a Provider,
    - AND if AS(i) has valid ASRA(s) and they do not include
      AS(i+1) as a customer or lateral peer,
    - then set Fake-Link(AS(i), AS(i+1)) = Detected,
    - Else, set Fake-Link(AS(i), AS(i+1)) = Not Detected.

    1. If the outcome is Invalid, it remains unchanged and the procedure halts.
    2. Else, if min_up_ramp = N, then also the outcome remains unchanged (Valid)
       and the procedure halts.
    3. Else, let i = min_up_ramp.
    4. If Fake-Link(AS(i), AS(i+1)) = Detected, then change
       the outcome to Invalid and the procedure halts.
    5. Else, if i = N - 1, then the procedure halts
       (outcome remains unchanged).
    6. Else, increment i to i+1. Go to Step #4.

5. Operational Considerations

Every AS operator doing ASPA/ASRA SHOULD periodically check their own ASPA/ASRA objects for correctness and completeness. They SHOULD also ensure that the same are refreshed well before their expiry dates.¶

Every AS operator doing ASPA SHOULD periodically monitor all the ASPAs in the RPKI repositories to check if their AS number is incorrectly included as a provider in an ASPA (X.509 valid), and if so, they SHOULD report it to the responsible party (or parties) so that the ASPA can be rectified.¶

Every AS operator doing ASPA SHOULD periodically monitor all the ASPAs in the RPKI repositories to check if their AS number is incorrectly not included as a provider in the ASPA of a customer AS (CAS), and if so, they SHOULD report it to the CAS operator so that the ASPA can be rectified.¶

Every AS operator doing ASRA SHOULD periodically monitor all the ASRAs in the RPKI repositories to check if their AS number is incorrectly included (or incorrectly not included) in an ASRA (X.509 valid), and if so, they SHOULD report it to the responsible party (or parties) so that the ASRA can be rectified.¶

6. Security Considerations

Security concerns for AS path verification using ASPA and ASRA are largely alleviated if the operational recommendations (Section 5) are followed.¶

7. IANA Considerations

This document does not have IANA considerations.¶

8. Acknowledgements

The authors wish to thank Mingqing (Michael) Huang, Jeff Haas, Doug Montgomery, and Oliver Borchert for very helpful comments and discussions.¶

9. References

Authors' Addresses