AS Hijacking Detection and Mitigation in the Presence of Regionalized ROAs

defines Route Origin Validation (ROV), which uses Route Origin Authorizations (ROAs) issued within the Resource Public Key Infrastructure (RPKI) 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).

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:

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: A schema for carrying Region Identifiers in ROAs (Regionalized ROA). Extensions to the RPKI-Router Protocol [RFC8210] to propagate Region Identifiers to routers. Enhanced Route Origin Validation procedures incorporating Regional Context (R-ROV) to detect cross-regional hijacking.

ROV: Route Origin Validation . 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 . 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 . A new PDU or an extended field in the IPv4/IPv6 Prefix PDU is introduced:

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 ). The enhanced local cache presented on the router is structured as:

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 (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. Case A (Unscoped ROA): If Region_ROA is empty or set to 'Global' (0x0000), return Valid. Case B (Scoped ROA Check): If Region_ROA is specified: Compare Region_ROA with Region_Ctx (Ingress/Observed Region). If Region_ROA == Region_Ctx: Return Valid. If Region_ROA != Region_Ctx: Return RegionMismatch (or Invalid_Region).

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: A new PDU Type in the RPKI-Router Protocol (RTR) Registry [RFC8210] for "IPv4/IPv6 Prefix with Region PDU". A new Registry for "RPKI Region Identifiers".

The following people made significant contributions to this document:

TBD.