| Internet-Draft | Regionalized ROAs | September 2026 |
| Geng, et al. | Expires 24 March 2027 | [Page] |
Resource Public Key Infrastructure (RPKI) Route Origin Validation (ROV) verifies whether an Autonomous System (AS) is authorized to originate a given IP prefix. However, multi-national or geographically dispersed ASes often hold IP prefix allocations from different Regional Internet Registries (RIRs) or announce specific prefixes only within designated geographic regions under a single Origin AS. An attacker located in a different region can maliciously announce an authorized prefix under the same legitimate Origin AS, effortlessly bypassing standard RPKI ROV. This document defines the concept of "Regionalized ROA" (R-ROA), specifies protocol enhancements to convey regional scope metadata from Trust Anchors down to routers via RPKI-Router protocol extensions, and outlines enhanced validation procedures to detect and mitigate intra-AS cross-regional route hijacking.¶
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 24 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.¶
[RFC6811] defines Route Origin Validation (ROV), which uses Route Origin Authorizations (ROAs) issued within the Resource Public Key Infrastructure (RPKI) [RFC6480] to verify whether a BGP route's Origin AS is authorized to announce a specific IP prefix. While ROV effectively prevents traditional Origin AS hijacking, it cannot detect attacks where the attacker spoofs the legitimate Origin AS or where an attacker within a legitimate AS re-announces a regionally restricted prefix in an unauthorized geographic zone.¶
In operational networks, large enterprise networks, content delivery networks (CDNs), and global Tier-1 service providers frequently hold IP address blocks allocated across multiple Regional Internet Registries (RIRs), such as RIPE NCC, APNIC, and ARIN, while utilizing a single globally unique Autonomous System Number (ASN).¶
+---------------+---------+------------------------+------------+ | Prefixes | Origin | Source RIR / Trust | Intended | | | AS | Anchor (TA) | Region | +---------------+---------+------------------------+------------+ | 10.1.0.0/16 | AS64596 | RIPE NCC RPKI Root | Europe | | 10.2.0.0/16 | AS64596 | APNIC RPKI Root | Asia | | 10.3.0.0/16 | AS64596 | ARIN RPKI Root | N. America | +---------------+---------+------------------------+------------+ Figure 1: Geographically Dispersed Prefix Usage¶
Note: The addresses used in Figure 1 are for illustrative purposes.¶
Under current specifications, RPKI Relying Parties (RPs) and routers ingest ROAs into an Ingress Validation Database without regional or RIR context. When viewed on a BGP router, the ROA cache presents an undifferentiated list:¶
Command: show ip bgp rpki table ----------------------------------------------------------------- Network Maxlen Origin-AS Source Neighbor 10.1.0.0/16 16 64596 0 192.168.160.2/43779 10.2.0.0/16 16 64596 0 192.168.160.2/43779 10.3.0.0/16 16 64596 0 192.168.160.2/43779 ----------------------------------------------------------------- Figure 2: Legacy ROA Table¶
Consider a scenario where AS64596 intends for 10.2.0.0/16 to be announced exclusively in Asia (APNIC region). An attacker (or an unauthorized edge node) located in Europe originates a BGP announcement for 10.2.0.0/16 with Origin AS64596 into European transit networks.¶
Because the ROA database authorizes (10.2.0.0/16, AS64596) globally, standard [RFC6811] ROV marks this illegitimate announcement as 'Valid'. If the malicious path in Europe offers a shorter AS-PATH or better BGP metrics, European traffic destined for 10.2.0.0/16 will be hijacked.¶
This vulnerability exists because regional authorization metadata inherent to RIR allocations and ROA issuance is stripped before reaching the router's decision engine. This document specifies:¶
R-ROA: Regionalized Route Origin Authorization. A ROA augmented with a standardized Region Identifier.¶
R-ROV: Regionalized Route Origin Validation. The enhanced validation logic executing on BGP Speakers.¶
Region Identifier (Region-ID): A standardized identifier encoding a geographical or administrative scope (e.g., ISO 3166-1 country code, UN M49 region code, or RIR Authority Code).¶
RIR: Regional Internet Registry¶
RP: Relying Party¶
RPKI: Resource Public Key Infrastructure¶
An extended ROA object payload is defined by incorporating an optional `RegionIdentifier` attribute within the ROA eContent structure [RFC9582].¶
RegionIdentifier CHOICE {¶
rirCode ENUMERATED { ripe(1), apnic(2), arin(3), lacnic(4), afrinic(5) },¶
isoCountryCode PrintableString (SIZE (2)), -- ISO 3166-1 alpha-2¶
unRegionCode INTEGER (0..999) -- UN M49 numeric¶
}¶
When an IP Resource Holder creates a ROA, it optionally binds the Prefix to its designated operational region.¶
To transport R-ROAs from Relying Party (RP) caches to routers, this document extends the RTR PDU definitions [RFC8210].¶
A new PDU or an extended field in the IPv4/IPv6 Prefix PDU is introduced:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (2) | PDU Type (n) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Length | Max Length | Region-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix / IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Extended RTR Prefix PDU
¶
Region-ID: A 16-bit unsigned integer representing the authoritative RIR or geographical scope (e.g., 0x0001 = RIPE, 0x0002 = APNIC, 0x0003 = ARIN).¶
In environments where RPKI objects cannot be updated immediately, the RP or local management plane MAY synthesize an Enhanced ROA Database by ingesting RIR Delegated Stats files and Geolocation databases (e.g., Geolocation Data in RPKI [RFC9632]).¶
The enhanced local cache presented on the router is structured as:¶
Command: show ip bgp rpki table
--------------------------------------------------------------------
Network Maxlen Origin-AS Source Neighbor Region-ID
10.1.0.0/16 16 64596 0 192.168.160.2 RIPE-NCC (EU)
10.2.0.0/16 16 64596 0 192.168.160.2 APNIC (AS)
10.3.0.0/16 16 64596 0 192.168.160.2 ARIN (NA)
--------------------------------------------------------------------
Figure 4: Enhanced R-ROA Local Table
¶
To compare the expected ROA Region-ID against the actual path region, the validating BGP speaker MUST establish the "Received Region Context" (Region_Ctx) of an incoming BGP UPDATE. Region_Ctx is determined via one or more of the following control-plane mechanisms:¶
Ingress Peer Configuration: BGP sessions are explicitly mapped to a Region-ID based on physical peering location or peer configuration.¶
BGP Communities / Large Communities: Ingress border routers tag incoming routes with administrative location communities [RFC8092] (e.g., Target Region Community).¶
Control-Plane Telemetry & BGP-LS: The router correlates BGP update ingress points with network topology data.¶
When a BGP speaker receives an UPDATE for prefix P with Origin AS A from an ingress peer with determined context Region_Ctx:¶
Step 1: Perform Standard RFC 6811 Validation¶
--------------------------------------------¶
Look up (P, A) in the Validation Database.¶
If match state is 'NotFound', return NotFound (Process per RFC 6811).¶
If match state is 'Invalid' (Origin AS mismatch or length exceeded), return Invalid (Reject or Deprioritize per RFC 6811).¶
If match state is 'Valid', proceed to Step 2.¶
Step 2: Regional Scope Evaluation (R-ROV)¶
--------------------------------------------¶
Retrieve the Region-ID (Region_ROA) associated with the matching ROA entry.¶
Routes yielding a 'RegionMismatch' validation state SHOULD be handled according to local routing policy:¶
Hard Drop: Reject the route to prevent cross-regional traffic leakage.¶
Local Preference Penalty: Lower the BGP `LOCAL_PREF` attribute substantially (e.g., set to 10) so that legitimate local announcements or alternative paths are strictly preferred.¶
Alarm and Logging: Generate syslog/NETCONF notification telemetry flagging potential intra-AS cross-regional hijacking.¶
Spoofed Peering Context: If an attacker injects routes via an IBGP or EBGP session where Region_Ctx is misconfigured, false positives or negatives may occur. Operators MUST securely bind Region_Ctx to ingress interfaces.¶
Transition and Backward Compatibility: Unextended routers will ignore the Region-ID field in RTR PDUs (or process standard RFC 6811 entries), ensuring full backward compatibility.¶
Geolocation Spoofing: Out-of-band Region-ID compilation relying on unverified Geolocation data could lead to invalid route drops. Standardized RPKI-signed location metadata [RFC9632] SHOULD be prioritized.¶
This document requests IANA to allocate:¶
The following people made significant contributions to this document:¶
TBD¶
TBD.¶