AS Hijacking Detection and Mitigation in the Presence of Regionalized ROAs
draft-geng-sidrops-regionalized-roa-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Nan Geng , Shunwan Zhuang , Haibo Wang , Longfei Dai | ||
| Last updated | 2026-09-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-geng-sidrops-regionalized-roa-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
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,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8210>.
[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,
<https://www.rfc-editor.org/info/rfc9582>.
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, <https://www.rfc-editor.org/info/rfc6480>.
[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,
<https://www.rfc-editor.org/info/rfc8092>.
[RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley,
"Finding and Using Geofeed Data", RFC 9632,
DOI 10.17487/RFC9632, August 2024,
<https://www.rfc-editor.org/info/rfc9632>.
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]