Network Working Group N. Geng Internet-Draft S. Zhuang Intended status: Standards Track H. Wang Expires: 24 March 2027 L. Dai Huawei Technologies 20 September 2026 AS Hijacking Detection and Mitigation in the Presence of Regionalized ROAs draft-geng-sidrops-regionalized-roa-00 Abstract 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. 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. 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/. Geng, et al. Expires 24 March 2027 [Page 1] Internet-Draft Regionalized ROAs September 2026 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 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 . . . . . . . . . . . . . . . . . . 4 3. Regionalized ROA Architecture and Protocol Extensions . . . . 4 3.1. Option 1: Cryptographic In-Band Extension (R-ROA Extension) . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. RPKI-Router Protocol (RTR) Extensions . . . . . . . . . . 5 3.3. Option 2: Local Out-of-Band Management Database . . . . . 6 4. Operational Validation and Hijacking Mitigation (R-ROV) . . . 6 4.1. Router Locality & Ingress Context Identification . . . . 6 4.2. Validation Workflow . . . . . . . . . . . . . . . . . . . 6 4.3. Mitigation Actions . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Geng, et al. Expires 24 March 2027 [Page 2] Internet-Draft Regionalized ROAs September 2026 1. Introduction [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 Geng, et al. Expires 24 March 2027 [Page 3] Internet-Draft Regionalized ROAs September 2026 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: 1. A schema for carrying Region Identifiers in ROAs (Regionalized ROA). 2. Extensions to the RPKI-Router Protocol [RFC8210] to propagate Region Identifiers to routers. 3. Enhanced Route Origin Validation procedures incorporating Regional Context (R-ROV) to detect cross-regional hijacking. 2. Definitions and Acronyms * ROV: Route Origin Validation [RFC6811]. * 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 3. Regionalized ROA Architecture and Protocol Extensions Geng, et al. Expires 24 March 2027 [Page 4] Internet-Draft Regionalized ROAs September 2026 3.1. Option 1: Cryptographic In-Band Extension (R-ROA Extension) 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. 3.2. RPKI-Router Protocol (RTR) Extensions 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). Geng, et al. Expires 24 March 2027 [Page 5] Internet-Draft Regionalized ROAs September 2026 3.3. Option 2: Local Out-of-Band Management Database 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 4. Operational Validation and Hijacking Mitigation (R-ROV) 4.1. Router Locality & Ingress Context Identification 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: 1. Ingress Peer Configuration: BGP sessions are explicitly mapped to a Region-ID based on physical peering location or peer configuration. 2. BGP Communities / Large Communities: Ingress border routers tag incoming routes with administrative location communities [RFC8092] (e.g., Target Region Community). 3. Control-Plane Telemetry & BGP-LS: The router correlates BGP update ingress points with network topology data. 4.2. Validation Workflow 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 Geng, et al. Expires 24 March 2027 [Page 6] Internet-Draft Regionalized ROAs September 2026 -------------------------------------------- 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). 4.3. Mitigation Actions Routes yielding a 'RegionMismatch' validation state SHOULD be handled according to local routing policy: 1. Hard Drop: Reject the route to prevent cross-regional traffic leakage. 2. 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. 3. Alarm and Logging: Generate syslog/NETCONF notification telemetry flagging potential intra-AS cross-regional hijacking. Geng, et al. Expires 24 March 2027 [Page 7] Internet-Draft Regionalized ROAs September 2026 5. Security Considerations * 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. 6. IANA Considerations This document requests IANA to allocate: 1. A new PDU Type in the RPKI-Router Protocol (RTR) Registry [RFC8210] for "IPv4/IPv6 Prefix with Region PDU". 2. A new Registry for "RPKI Region Identifiers". 7. Contributors The following people made significant contributions to this document: TBD 8. Acknowledgements TBD. 9. References 9.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, . Geng, et al. Expires 24 March 2027 [Page 8] Internet-Draft Regionalized ROAs September 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, . [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, . [RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, . 9.2. Informative References [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, I., and N. Hilliard, "BGP Large Communities Attribute", RFC 8092, DOI 10.17487/RFC8092, February 2017, . [RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9632, DOI 10.17487/RFC9632, August 2024, . Authors' Addresses Nan Geng Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: gengnan@huawei.com Geng, et al. Expires 24 March 2027 [Page 9] Internet-Draft Regionalized ROAs September 2026 Shunwan Zhuang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: zhuangshunwan@huawei.com Haibo Wang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: rainsword.wang@huawei.com Longfei Dai Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: larry.dai@huawei.com Geng, et al. Expires 24 March 2027 [Page 10]