SIDROPS C. Shen Internet-Draft CAICT Intended status: Standards Track N. Geng Expires: 2 March 2027 Huawei Technologies Y. Liu China Mobile W. Yu CAICT H. Wang S. Zhuang S. Chen Huawei Technologies 29 August 2026 Verification of Routes Using Region Authorization draft-shen-sidrops-region-verification-05 Abstract 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. 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. Shen, et al. Expires 2 March 2027 [Page 1] Internet-Draft Region-Based Route Verification August 2026 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 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Route Hijacking Risk Within a Single ISP . . . . . . . . 3 3.2. Route Hijacking Risk Between Multiple ISPs . . . . . . . 5 4. Region-Based Authorization (RBA) . . . . . . . . . . . . . . 6 4.1. RBA ASN.1 Module . . . . . . . . . . . . . . . . . . . . 6 5. Region-Based Verification Procedure . . . . . . . . . . . . . 7 5.1. Single Region Verification . . . . . . . . . . . . . . . 7 5.2. Multiple Region (Confederation) Verification . . . . . . 8 5.3. Obtaining Region Information . . . . . . . . . . . . . . 9 5.4. Comparison with Routing Policy Solutions . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. RPKI Signed Object Content Type . . . . . . . . . . . . . 9 6.2. RPKI Repository Object EXTENSION . . . . . . . . . . . . 10 6.3. RPKI-RTR PDU Types . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 Shen, et al. Expires 2 March 2027 [Page 2] Internet-Draft Region-Based Route Verification August 2026 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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. 2. Terminology OV: Origin Validation RPKI: Resource Public Key Infrastructure RP: Relying Party RBA: Region Based Authorization 3. Problem Statement 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. 3.1. Route Hijacking Risk Within a Single ISP Shen, et al. Expires 2 March 2027 [Page 3] Internet-Draft Region-Based Route Verification August 2026 /--------------------------\ | 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. Shen, et al. Expires 2 March 2027 [Page 4] Internet-Draft Region-Based Route Verification August 2026 3.2. Route Hijacking Risk Between Multiple ISPs /---------------------\ /--------------------\ | 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. Shen, et al. Expires 2 March 2027 [Page 5] Internet-Draft Region-Based Route Verification August 2026 4. Region-Based Authorization (RBA) A Region-Based Authorization (RBA) is a digitally signed RPKI object expressing geographic or administrative domain boundaries. An RBA object defines two key bindings: 1. 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. 2. 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. 4.1. RBA ASN.1 Module Shen, et al. Expires 2 March 2027 [Page 6] Internet-Draft Region-Based Route Verification August 2026 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 5. Region-Based Verification Procedure This section specifies the region-based route validation logic. Region verification acts as an additional validation check alongside standard RPKI Origin Validation (OV). 5.1. Single Region Verification 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: Shen, et al. Expires 2 March 2027 [Page 7] Internet-Draft Region-Based Route Verification August 2026 1. 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. 2. Check whether the origin AS of the route belongs to the Local Region. 3. 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. 4. 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. 5. 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. 5.2. Multiple Region (Confederation) Verification 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: 1. 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. 2. 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. 3. If the peer does NOT belong to the Local Region Confederation, the confederation verification state MUST be set to Invalid. 4. (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. Shen, et al. Expires 2 March 2027 [Page 8] Internet-Draft Region-Based Route Verification August 2026 Routes evaluated as Confederation-Invalid MUST NOT be selected as best paths over legitimate intra-confederation routes. 5.3. Obtaining Region Information Routers CAN obtain RBA and Region mapping data via two mechanisms: 1. 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) 2. Static Local Configuration: Routers are manually configured with Region and Confederation AS sets when RPKI deployment is incomplete. 5.4. Comparison with Routing Policy Solutions 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. 6. IANA Considerations [Note to IANA: This section will be updated prior to publication.] This document requests IANA to perform the following actions: 6.1. RPKI Signed Object Content Type 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: Shen, et al. Expires 2 March 2027 [Page 9] Internet-Draft Region-Based Route Verification August 2026 Decimal | Description | Document --------+------------------------------------+---------------+ TBD1 | id-ct-regionAuthorization | This-Document 6.2. RPKI Repository Object EXTENSION 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 6.3. RPKI-RTR PDU Types 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 7. Security Considerations 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. 8. Acknowledgements The authors would like to thank the IETF SIDROPS Working Group members for their valuable feedback and discussion. 9. References 9.1. Normative References Shen, et al. Expires 2 March 2027 [Page 10] Internet-Draft Region-Based Route Verification August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.ietf-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa- verification-28, 24 August 2026, . [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, . Authors' Addresses Chen Shen CAICT No.52, Hua Yuan Bei Road Beijing 100191 China Email: shenchen@caict.ac.cn Nan Geng Huawei Technologies Huawei Campus, No. 156 Beiqing Road Shen, et al. Expires 2 March 2027 [Page 11] Internet-Draft Region-Based Route Verification August 2026 Beijing 100095 China Email: gengnan@huawei.com Yisong Liu China Mobile 32 Xuanwumenxi Ave. Beijing 100032 China Email: liuyisong@chinamobile.com Wenyan Yu CAICT No.52, Hua Yuan Bei Road Beijing 100191 China Email: yuwenyan@caict.ac.cn Haibo Wang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: rainsword.wang@huawei.com Shunwan Zhuang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: zhuangshunwan@huawei.com Shuanglong Chen Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Shen, et al. Expires 2 March 2027 [Page 12] Internet-Draft Region-Based Route Verification August 2026 Email: chenshuanglong@huawei.com Shen, et al. Expires 2 March 2027 [Page 13]