| Internet-Draft | Regionalized AS-Relationships | August 2026 |
| Shen, et al. | Expires 2 March 2027 | [Page] |
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.¶
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.¶
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 2 March 2027.¶
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.¶
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.¶
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, ...]).¶
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:¶
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.¶
The AS_PATH received by the Verifying AS contains the segment (AS1, AS2).¶
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.¶
To resolve validation ambiguities caused by regionalized AS-relationships, the verification process MUST incorporate regional context.¶
Extend the ASPA RPKI object payload to include an optional Region Identifier (Region ID) field.¶
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.¶
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.¶
With regionalized AS-relationships enabled, the verification algorithm at the RVR is updated as follows for the scenario in Figure 3:¶
The Verifying AS receives Route P1 with AS_PATH containing segment (AS1, AS2).¶
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]).¶
The RVR queries the ASPA database for AS1. The retrieved ASPA record is ASPA (AS1, Providers: [AS2], Region: Europe).¶
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.¶
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.¶
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.¶
The following people made significant contributions to this document:¶
TBD¶
TBD.¶