ASPA Verification in the Presence of Regionalized AS-Relationships

RPKI-based Origin Validation (ROA) 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) 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.

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

Commercial interconnection agreements frequently exhibit regional variations. Figure 1 and Figure 2 illustrate two typical scenarios of hybrid AS relationships:

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.

Case 2: AS3 is a customer of AS4 in Europe, whereas AS4 is a customer of AS3 in Asia. Under the current specification , AS1 in Case 1 issues a single ASPA record authorizing AS2 as its provider: ASPA (Customer AS: AS1, Providers: [AS2, ...]).

\ / ----> \ 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) 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 ). 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 . 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.