| Internet-Draft | Region-Based Route Verification | August 2026 |
| Shen, et al. | Expires 2 March 2027 | [Page] |
BGP routing security is a critical issue affecting the stability and reliability of Internet services. Existing mechanisms, including Route Origin Authorization (ROA) and Autonomous System Provider Authorization (ASPA), effectively mitigate route origin hijacking, path hijacking, and route leaks in general scenarios. However, in real-world deployments, large Internet Service Providers (ISPs) managing multiple Autonomous Systems (ASes) remain vulnerable. Attacking networks can exploit carefully crafted routes to bypass ROA and ASPA validations, causing traffic hijacking within or between large ISPs.¶
This document defines a region-based authorization and verification framework for multi-AS ISPs to prevent intra-ISP and inter-ISP traffic 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 2 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.¶
The Border Gateway Protocol (BGP) was originally designed without built-in cryptographic mechanisms to validate route attributes, making it susceptible to BGP hijacking and route leaks [RFC7908].¶
RPKI-based Origin Validation (OV) [RFC6811] allows BGP routers to verify the origin AS of prefixes, mitigating basic origin AS hijacking. Furthermore, ASPA-based path verification [I-D.ietf-sidrops-aspa-verification] introduces AS-pair authorization to detect AS-Path hijacking and route leaks.¶
However, when large ISPs managing complex multi-AS networks deploy these technologies, security blind spots remain. An attacker can construct valid-looking paths that bypass both ROA and ASPA validation, leading to traffic hijacking across sub-ASes within or between large ISPs.¶
OV: Origin Validation¶
RPKI: Resource Public Key Infrastructure¶
RP: Relying Party¶
RBA: Region Based Authorization¶
Large ISPs frequently operate multiple public ASes to manage extensive geographic or functional domains. Typically, only a subset of these ASes (border ASes) establish eBGP peering with external ISPs, while internal sub-ASes exchange routes to serve different customer segments. Under this topology, route exchanges between sub-ASes remain vulnerable to crafted path-hijacking attacks.¶
/--------------------------\
| ISP1 |
+----+ | ,.., |
|user| | / \ |
| |-----| AS | |
+----+ | |65002 - |
| \ / `. |
| `'-` \ ,.., | /--------\
| `. / \ | | ISP10 |
| ' AS --------- |
| ,65001 | | | AS65500|
| / \ / | | |
| / `'-` | \--------/
| ,.., / |
| / \ / |
+----+ | | AS / |
|serv-------|65003 | |
|er | | \ / |
+----+ | `'-` |
| |
\--------------------------/
Figure 1: Route Hijacking Risk Within a Single ISP¶
As shown in Figure 1, ISP1 consists of AS65001, AS65002, and AS65003, and connects to an external ISP (AS65500) via AS65001. A server is connected to AS65003, and a user is connected to AS65002. AS65003 advertises the server's route to AS65002 (via AS65001 or directly), enabling the user to access the server.¶
When external AS65500 learns this prefix, it can forge a route by spoofing the origin AS as AS65003. AS65500 then advertises this forged route with AS-Path {AS65500, AS65003} back to AS65001. If AS65001 receives both the legitimate route from AS65003 and the forged route from AS65500, local preference or path selection rules may cause AS65001 (or AS65002) to prefer the route via AS65500. Consequently, traffic from the user to the server is hijacked to AS65500.¶
In practical deployments, ROA max-length parameters or broad prefix aggregations configured for traffic engineering expand the attack surface, allowing AS65500 to easily succeed by announcing more-specific prefixes with the spoofed origin AS.¶
Standard ASPA cannot prevent this attack because the AS-pair (AS65500, AS65003) may be registered as a valid provider relationship or cannot be flagged as Invalid if customer-provider relationships are not fully strictly constrained across international borders.¶
/---------------------\ /--------------------\
| ISP1 | | ISP2 |
+----+ | ,-. | | ,-. |
|user| | / \ | | / \ |
| |-----| AS | | | | AS | |
+----+ | |65002\ | | |65106| |
| \ / \ ,-. | | ,-. .\ / |
| '-' \ / \ | | / \ ` '-' |
| '| AS | | | | AS |-` |
| ,-. .|65001------------|65104| ,-. |
| / \ ` \ / | | \ / `. / \ | +----+
| | AS -` '\' | | '\' '| AS | | |serv|
| |65003| \ | | , |65105|-----|er |
| \ / , | | / \ / | +----+
| '-' \ | | / '-' |
\------------------\--/ \-/------------------/
\ .'
\ /
\ /
/------\---/--------\
| '.-, |
| / \ |
| | AS | |
| |65500 | |
| \ / |
| `'-` |
| ISP3 |
\-------------------/
Figure 2 Route hijacking risk between multiple ISPs
¶
As shown in Figure 2, ISP1 (comprising AS65001, AS65002, AS65003) peers with ISP2 (comprising AS65104, AS65105, AS65106) via AS65001-AS65104. Both ISP1 and ISP2 connect independently to an external transit provider, ISP3 (AS65500). A server is connected to AS65105, and a user is connected to AS65002. AS65105 advertises the server prefix to ISP1 via AS65104.¶
AS65500 can also receive the server prefix from AS65104/AS65105. AS65500 can spoof a route with a more-specific prefix, keeping origin AS65105 and AS-Path {AS65500, AS65104, AS65105}, and announce it to AS65001. If AS65001 prefers this path, traffic from the user to the server in ISP2 will be diverted to AS65500.¶
This multi-ISP scenario similarly circumvents standard ASPA validation.¶
A Region-Based Authorization (RBA) is a digitally signed RPKI object expressing geographic or administrative domain boundaries. An RBA object defines two key bindings:¶
ASN-to-Region Binding: Binds a set of ASNs owned by a single ISP to a unique Region ID. The RBA is signed by the administrative authority of the ISP, asserting that these ASNs belong to the same domain. An ASN MUST belong to at most one Region.¶
Region-to-Confederation Binding: Binds an ISP's Region ID to a Region Confederation ID, representing a coalition of administrative domains (e.g., mutually trusted partner ISPs).¶
Region IDs and Region Confederation IDs are managed and allocated under a unified RPKI registry structure.¶
RBA-2026
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) mod(0) TBD3 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ASId
FROM RPKI-Init-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) mod(0) 52 } ;
-- RBA Content Type OID allocation
id-ct-regionAuthorization OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) TBD1 }
-- Main RBA Syntax
RegionAuthorization ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
localRegionId RegionId,
asSet SEQUENCE (SIZE (1..MAX)) OF ASId,
confederationId RegionConfederationId OPTIONAL
}
RegionId ::= INTEGER (0..4294967295)
RegionConfederationId ::= INTEGER (0..4294967295)
END
¶
This section specifies the region-based route validation logic. Region verification acts as an additional validation check alongside standard RPKI Origin Validation (OV).¶
Taking Figure 1 as an example, ISP1's ASes (AS65001, AS65002, AS65003) are configured into Region 1.¶
When a BGP speaker receives a route, it validates whether the route is a local region route using the following procedure:¶
Perform standard RPKI Origin Validation (OV). If the OV result is Invalid, process according to standard RFC 6811 rules. If Valid, proceed to region verification.¶
Check whether the origin AS of the route belongs to the Local Region.¶
If the origin AS does not belong to the Local Region, the route is classified as an external region route. No further single-region checks are required.¶
If the origin AS belongs to the Local Region, check whether the eBGP peer from which the route was learned belongs to the Local Region.¶
If the peer does NOT belong to the Local Region, the region verification state MUST be set to Invalid.¶
Routes evaluated as Region-Invalid SHOULD be treated as ineligible for best-path selection or assigned the lowest local preference, preventing internal routes leaked/spoofed by external ASes from being accepted.¶
For multi-ISP scenarios (Figure 2), ISP1 (Region 1) and ISP2 (Region 2) form Region Confederation 1.¶
The validation procedure for a BGP speaker in Region 1 is as follows:¶
Execute single-region verification (Section 5.1). If the route's origin AS does NOT belong to the Local Region, check whether it belongs to the Local Region Confederation.¶
If the origin AS belongs to the Local Region Confederation, check whether the eBGP peer from which the route was learned belongs to the Local Region Confederation.¶
If the peer does NOT belong to the Local Region Confederation, the confederation verification state MUST be set to Invalid.¶
(Optional) Verify whether the peer matches the specific origin Region. If the learned peer does not match the designated transit path for that Region within the confederation, the route SHOULD be assigned a lower preference.¶
Routes evaluated as Confederation-Invalid MUST NOT be selected as best paths over legitimate intra-confederation routes.¶
Routers CAN obtain RBA and Region mapping data via two mechanisms:¶
RPKI-RTR Protocol Extension: Relying Parties (RPs) fetch signed RBA objects from the RPKI repository and push validated data to BGP routers via an extended RPKI-RTR protocol. (RECOMMENDED)¶
Static Local Configuration: Routers are manually configured with Region and Confederation AS sets when RPKI deployment is incomplete.¶
While similar route filtering can theoretically be achieved using BGP AS- Path regular expressions (e.g., rejecting routes arriving from external peers whose origin AS belongs to the local ISP), this operational approach presents significant drawbacks:¶
High Management Complexity: Requires manually updating complex BGP route-maps across all edge routers whenever AS topologies change.¶
Error-Prone Integration: Hard to maintain consistency when combined with existing complex traffic engineering policies.¶
Automating region validation via RPKI/RBA eliminates manual policy drift and simplifies large-scale network operation.¶
[Note to IANA: This section will be updated prior to publication.]¶
This document requests IANA to perform the following actions:¶
IANA is requested to register an Object Identifier (OID) for the Region- Based Authorization (RBA) signed object in the "SMI Security for S/MIME CMS Content Type" registry [RFC7120] under the id-ct arc, as follows:¶
Decimal | Description | Document
--------+------------------------------------+---------------+
TBD1 | id-ct-regionAuthorization | This-Document
¶
IANA is requested to register the file extension ".rba" in the "RPKI Repository Object Extensions" registry, as follows:¶
Extension | RPKI Object | Document
----------+-----------------------------+---------------+
.rba | Region Authorization Object | This-Document
¶
This document requests IANA to allocate a new PDU type in the "RPKI-RTR PDU Types" registry for transmitting Region Authorization data to BGP routers:¶
PDU Type | Description | Document
---------+-------------------------------+---------------+
TBD2 | Region Authorization Data | This-Document
¶
This document introduces Region-Based Authorization (RBA) objects to prevent crafted path hijacking across multi-AS domain boundaries.¶
RBA relies on the underlying security of the RPKI Trust Anchor Architecture. If an unauthorized entity compromises an ISP's RPKI private key, it could publish fraudulent RBA records, potentially altering region boundaries.¶
Additionally, operators MUST ensure that all ASes belonging to a Region or Confederation are accurately maintained in the RPKI repository to avoid false-positive invalidations during legitimate route propagation.¶
The authors would like to thank the IETF SIDROPS Working Group members for their valuable feedback and discussion.¶