Network Working Group C. Shen Internet-Draft CAICT Intended status: Standards Track S. Zhang Expires: 2 March 2027 NNIX N. Geng S. Zhuang S. Chen H. Wang Huawei 29 August 2026 ASPA Verification in the Presence of Regionalized AS-Relationships draft-shen-sidrops-regionalized-as-relationships-04 Abstract Autonomous System Provider Authorization (ASPA) defines an RPKI-based methodology to validate the AS_PATH of BGP routes based on a global Customer-to-Provider (C2P) relationship model. However, in commercial Internet routing, two Autonomous Systems (ASes) may establish distinct business relationships across different geographical regions or interconnection points (e.g., Customer-to- Provider in one region, but Peer-to-Peer in another). Such regionalized or hybrid AS-relationships can lead to incorrect ASPA validation results (e.g., false "Valid" attestation for a route propagated over a P2P link). This document analyzes the vulnerabilities caused by regionalized AS-relationships and proposes mechanisms to incorporate regional granularity into ASPA objects and verification procedures. 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Shen, et al. Expires 2 March 2027 [Page 1] Internet-Draft Regionalized AS-Relationships August 2026 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 2 March 2027. Copyright Notice Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 3. Problem Statement: Regionalized AS-Relationships . . . . . . 4 4. Proposed Approaches for Regionalized ASPA . . . . . . . . . . 5 4.1. Option 1: Region-Aware ASPA Object Extension . . . . . . 5 4.2. Option 2: Local Management of Regional C2P Policies . . . 6 5. Verification Operations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Shen, et al. Expires 2 March 2027 [Page 2] Internet-Draft Regionalized AS-Relationships August 2026 1. Introduction RPKI-based Origin Validation (ROA) [RFC6811] mitigates basic prefix hijacking by verifying the origin AS of a BGP prefix. To protect the entire AS_PATH against route leaks and unauthorized path modifications, Autonomous System Provider Authorization (ASPA) [I-D.ietf-sidrops-aspa-verification] introduces a mechanism where a Customer AS cryptographically authorizes a set of Provider ASes capable of forwarding its routes upstream. The current ASPA verification model assumes a monolithic, globally uniform business relationship between any given pair of ASes. In reality, large multinational networks often establish regionalized (or hybrid) agreements. Two adjacent ASes may operate under a Customer-to-Provider (C2P) relationship in one continent, but maintain a Peer-to-Peer (P2P) or mutual-backup arrangement in another. When ASPA verification is performed without awareness of these regional boundaries, a route leaked across a P2P interconnection in one region may be incorrectly evaluated as "Valid" because a valid C2P ASPA record exists for those same two ASes in another region. This document describes the security impact of regionalized AS- relationships on ASPA and outlines enhancements to incorporate regional constraints into ASPA validation. 2. Definitions and Acronyms * ASPA: Autonomous System Provider Authorization * C2P: Customer to Provider * OV: Origin Validation * P2C: Provider to Customer * P2P: Peer to Peer * RP: Relying Party * RPKI: Resource Public Key Infrastructure * RVR: RPKI-Validating Router Shen, et al. Expires 2 March 2027 [Page 3] Internet-Draft Regionalized AS-Relationships August 2026 3. Problem Statement: Regionalized AS-Relationships Commercial interconnection agreements frequently exhibit regional variations. Figure 1 and Figure 2 illustrate two typical scenarios of hybrid AS relationships: Europe +----------------+ /Customer Provider \ / \ AS1--+ +--AS2 \ / \ Peer Peer/ +----------------+ Asia Figure 1: Hybrid Relationship (Case 1) Case 1: AS1 is a customer of AS2 in Europe (C2P), but AS1 and AS2 establish a Peer-to-Peer (P2P) settlement-free agreement in Asia. Europe +----------------+ /Customer Provider \ / \ AS3--+ +--AS4 \ / \ Provider Customer/ +----------------+ Asia Figure 2: Hybrid Relationship Case 2 Case 2: AS3 is a customer of AS4 in Europe, whereas AS4 is a customer of AS3 in Asia. Under the current specification [I-D.ietf-sidrops-aspa-verification], AS1 in Case 1 issues a single ASPA record authorizing AS2 as its provider: ASPA (Customer AS: AS1, Providers: [AS2, ...]). Shen, et al. Expires 2 March 2027 [Page 4] Internet-Draft Regionalized AS-Relationships August 2026 Europe +----------------+ /Customer Provider \ Route P1 / \ Origin AS11 .. AS1--+ +--AS2-- ... Check Point ---> \ / ----> \ Peer Peer/ +---------------+ Asia ----> Figure 3: Problematic Use Case Consider the scenario depicted in Figure 3: 1. A BGP update for Route P1 (originated by AS11) is propagated through AS1 to AS2 over the P2P link in Asia, and subsequently sent to the Verifying AS. 2. The AS_PATH received by the Verifying AS contains the segment (AS1, AS2). 3. According to the ASPA verification procedures, the Verifying AS checks the AS-pair (AS1, AS2) against AS1's ASPA record. Since AS2 is listed as a valid Provider for AS1, the evaluation yields a result of "Valid". However, because the route was transmitted across a P2P link in Asia, AS2 should NOT act as a transit provider for AS1 in this region. The correct semantic result for this hop ought to be "Invalid" (or a route leak condition). This false "Valid" attestation exposes the network to undetected route leaks. 4. Proposed Approaches for Regionalized ASPA To resolve validation ambiguities caused by regionalized AS- relationships, the verification process MUST incorporate regional context. 4.1. Option 1: Region-Aware ASPA Object Extension Extend the ASPA RPKI object payload to include an optional Region Identifier (Region ID) field. Shen, et al. Expires 2 March 2027 [Page 5] Internet-Draft Regionalized AS-Relationships August 2026 * When an AS registers its C2P relationships with its Regional Internet Registry (RIR), it MAY associate specific Provider ASes with a designated Region ID (e.g., UN/LOCODE, ISO 3166 continent codes, or an IANA-assigned Region Enum). * An ASPA record containing a Region ID indicates that the C2P relationship is valid ONLY for interconnections located within the specified region. * If the Region ID field is omitted or set to 0 (Wildcard/Global), the record maintains backward compatibility, indicating that the C2P relationship applies globally across all regions. The RPKI-Router Protocol (RTR) [RFC8210] is extended accordingly to deliver the Region ID metadata alongside ASPA payloads from RPs to RVRs. 4.2. Option 2: Local Management of Regional C2P Policies Network operators MAY locally construct an enhanced regional C2P database by analyzing global routing tables (e.g., Route Views, RIPE RIS) and local peering telemetry. These regional policy overrides are loaded directly into local routers to supplement or refine public ASPA records. 5. Verification Operations With regionalized AS-relationships enabled, the verification algorithm at the RVR is updated as follows for the scenario in Figure 3: 1. The Verifying AS receives Route P1 with AS_PATH containing segment (AS1, AS2). 2. The RVR determines the local or ingress geographical context (Region) of the interconnection link over which the BGP update was received (e.g., via ingress interface binding, BGP community tagging, or BGP OTC attribute evaluation [RFC9234]). 3. The RVR queries the ASPA database for AS1. The retrieved ASPA record is ASPA (AS1, Providers: [AS2], Region: Europe). Shen, et al. Expires 2 March 2027 [Page 6] Internet-Draft Regionalized AS-Relationships August 2026 4. The RVR compares the ingress link region (Asia) with the region specified in the ASPA record (Europe). Because the link region does not match the authorized region for the C2P relationship, the ASPA verification algorithm evaluates the (AS1, AS2) hop as "Invalid". By integrating regional checks into the ASPA evaluation logic, false positive validations are prevented, accurately reflecting the real- world topology. 6. IANA Considerations If Option 1 is adopted, this document will require IANA to allocate a new flag/field in the ASPA RPKI Object profile and extend the RTR Protocol PDU types [RFC8210]. Detailed registry requests will be specified in a future revision. 7. Security Considerations This document enhances ASPA verification accuracy by eliminating false "Valid" evaluations on regionalized links. Adding Region IDs does not weaken the cryptographic security of RPKI. However, operators must ensure that region bindings (e.g., ingress interface tagging) on local RVRs are accurately configured to avoid unintended "Invalid" outcomes. 8. Contributors The following people made significant contributions to this document: TBD 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Shen, et al. Expires 2 March 2027 [Page 7] Internet-Draft Regionalized AS-Relationships August 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . 10.2. Informative References [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-28, 24 August 2026, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", RFC 9234, DOI 10.17487/RFC9234, May 2022, . Authors' Addresses Chen Shen CAICT No.52, Hua Yuan Bei Road Beijing 100191 China Email: shenchen@caict.ac.cn Shicong Zhang NNIX No. 198, Qidi Road, Xiaoshan District Hangzhou 311200 China Shen, et al. Expires 2 March 2027 [Page 8] Internet-Draft Regionalized AS-Relationships August 2026 Email: zsc@nnix.cn Nan Geng Huawei 156 Beiqing Road Beijing 100095 China Email: gengnan@huawei.com Shunwan Zhuang Huawei 156 Beiqing Road Beijing 100095 China Email: zhuangshunwan@huawei.com Shuanglong Chen Huawei 156 Beiqing Road Beijing 100095 China Email: chenshuanglong@huawei.com Haibo Wang Huawei 156 Beiqing Road Beijing 100095 China Email: rainsword.wang@huawei.com Shen, et al. Expires 2 March 2027 [Page 9]