



SIDROPS                                                          C. Shen
Internet-Draft                                                     CAICT
Intended status: Standards Track                                 N. Geng
Expires: 3 September 2026                            Huawei Technologies
                                                                  Y. Liu
                                                            China Mobile
                                                                   W. Yu
                                                                   CAICT
                                                                 H. Wang
                                                               S. Zhuang
                                                                 S. Chen
                                                     Huawei Technologies
                                                            2 March 2026


           Verification of Routes Using Region Authorization
               draft-shen-sidrops-region-verification-03

Abstract

   BGP routing security is becoming a major issue that affects the
   normal running of Internet services.  Currently, there are many
   solutions, including ROA authentication and ASPA authentication, to
   prevent route source hijacking, path hijacking, and route leaking.
   However, on an actual network, large ISPs with multiple ASes can use
   carefully constructed routes to bypass ROA and ASPA authentication to
   attack the target network.

   This document defines an region-based authentication method for large
   ISPs with many ASes to prevent traffic hijacking within ISPs.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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/.





Shen, et al.            Expires 3 September 2026                [Page 1]

Internet-Draft  Verification of Routes Using Region Auth      March 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 3 September 2026.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   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  . . . . . . .   4
   4.  Region Based Authorization  . . . . . . . . . . . . . . . . .   6
   5.  Region Based Verification Procedure . . . . . . . . . . . . .   6
     5.1.  Singe region verification . . . . . . . . . . . . . . . .   6
     5.2.  Multiple region verification  . . . . . . . . . . . . . .   7
     5.3.  Obtaining Region Information  . . . . . . . . . . . . . .   7
     5.4.  Comparing with routing policy . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The design of the Border Gateway Protocol (BGP) lacks a mechanism to
   validate BGP attributes, which is prone to BGP hijacking and BGP
   route leaks [RFC7908].





Shen, et al.            Expires 3 September 2026                [Page 2]

Internet-Draft  Verification of Routes Using Region Auth      March 2026


   [RFC6811] defines a method for verifying the origin of BGP prefixes,
   which can resolve the most common source AS hijacking.
   [I-D.ietf-sidrops-aspa-verification] defines an AS-pairs based
   authentication method to resolve AS-Path hijacking and route leaking.

   However, even if these two technologies are deployed on large ISP
   networks with many ASes, there are still risks of being attacked by
   carefully constructed path hijacking.

2.  Terminology

   OV: Origin Validation

   RPKI: Resource Public Key Infrastructure

   RP: Relying Party

   RBA: Region Based Authorization

3.  Problem Statement

   Currently, some large ISPs have more than one public ASes to
   facilitate management.  In these ISPs, only one or very few ASes are
   used to connect to external ISPs.  However, the sub-ASes of these
   ISPs also exchange routes to provide services for different
   customers.  Therefore, the route access between these sub-ASes may
   still be subjected to a well-crafted attack.

3.1.  Route hijacking risk within a single ISP






















Shen, et al.            Expires 3 September 2026                [Page 3]

Internet-Draft  Verification of Routes Using Region Auth      March 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 the Figure 1.  ISP1 has AS65001, AS65002, and AS65003 and
   connects to an external ISP, such as AS65500.  There is a server
   connect to the AS65003, and a user connecte to the AS65002.  AS65003
   advertises the server's route to AS65002, and AS65002 uses the route
   to provide services for users.

   After the AS65500 obtains the route for the server, it can spoof the
   route and change the source AS to AS65003.  In this way, the spoofed
   route is advertised to AS65001 with AS-Path AS65500 AS65003.  AS65001
   selects routes between the routes advertised by AS65003 and AS65500.
   Therefore, AS65001 may preferentially select the forged routes of
   AS65500.  As a result, subsequent traffic from users to the server is
   hijacked to AS65500.

   IIn actual deployment, to facilitate traffic adjustment, the mask of
   the address in the ROA database registered by ISP1 may be in a
   certain range.  In this case, the AS65500 can more easily hijack
   traffic by using more specific prefixes and spoofing the source AS.

   The scenario described here can be prevented by ASPA because the AS
   pair (AS65500,AS65003) does not exist..

3.2.  Route hijacking risk between multiple ISPs





Shen, et al.            Expires 3 September 2026                [Page 4]

Internet-Draft  Verification of Routes Using Region Auth      March 2026


            /---------------------\      /--------------------\
            |         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 has AS65001, AS65002, and AS65003 and
   connects to external ISPs, such as AS65500 and ISP2's AS65104.  ISP2
   has AS65104, AS65105, and AS65106, and connects to external ISPs such
   as AS65500 and ISP1's AS65001.  There is a server connect to AS65105,
   and a user connect to AS65002.  AS65105 advertises the server's route
   to AS65002 through the BGP peer.  AS65002 then provides services for
   users.

   The AS65500 can also obtain the route for the server from AS65104.
   The AS65500 can spoof the route of the server and change the source
   AS to AS65105.  In this way, the AS65500 constructs a more specific
   prefix, which AS-Path is AS65500 AS65104 AS65105, and advertises the
   route to AS65001.  The traffic from the user to the server will be
   hijacked to AS65500.

   In this scenario it also can't be prevented by ASPA.





Shen, et al.            Expires 3 September 2026                [Page 5]

Internet-Draft  Verification of Routes Using Region Auth      March 2026


4.  Region Based Authorization

   An RBA is a digital signature object that contains two types of data.
   One type is to bind multiple ASNs of an ISP to an region ID.  The
   region ID represents the ISP and is signed by the administrator of
   the ISP.  The RBA certifies which ASNs an ISP has.  An AS should
   belongs to only one ISP.  The second type is to bind an ISP's region
   ID to a region confederation ID, which is signed by the ISP's
   administrator.  The region ID and region confederation ID introduced
   here can be allocated and managed by a unified structure.

5.  Region Based Verification Procedure

   To solve this problem, a region-based verification is introduced.
   This method is applicable to large ISPs with multiple ASes.  In
   addition to OV verification, region-based verification is performed
   to prevent the attack scenarios mentioned in section 3.

5.1.  Singe region verification

   As shown in Figure 1, ISP1 can be set to area 1, including AS65001,
   AS65002, and AS65003.

   When a device learns a route, it will verifie whether the route is a
   local region route based on basic OV verification.

   The verification process is as follows:

   1) Perform OV verification on the route.  If the OV verification
   result is valid, then perform area verification.

   2) Check whether the route's origin AS is belong to local region.

   3) If not, it indicates that the route is not a local region route.
   No additional verification is required in single region scenarios..

   4) If the route's origin AS is belong to local region, check whether
   the peer that learns the route is belong to local region.

   5) If the peer that learns a route is not belong to local region, the
   route verification result is invalid.

   If the route verification result is invalid, the route can be
   consider as an invalid route and is not involved in route selection.
   This prevents routes belong to local region from being learned by
   external ASs and prevents possible route hijacking.





Shen, et al.            Expires 3 September 2026                [Page 6]

Internet-Draft  Verification of Routes Using Region Auth      March 2026


5.2.  Multiple region verification

   For the case of Figure 2, region confederations can be set.  ISP1 is
   set to region 1, including AS65001, AS65002, and AS65003.  ISP2 is
   set to region 2, including AS65104, AS65105, and AS6.  In addition,
   the region of ISP1 and ISP2 form a regional confederation, which is
   set to regional confederation 1.

   The verification process is as follows:

   1) First, perform the step of region verification.  After single
   region verification step 2, if the route's origin AS is not belong to
   local region, then check whether the route belongs to the local
   confederation.

   2) If the route belongs to the local confederation, check whether the
   peer that learned the route is belong to the local confederation.

   3) If the peer is not belong to the local confederation, the route
   verification result is invalid.

   4) Optionally, further checking whether the peer is the region to
   which the route belongs maybe done.  If the region to which the route
   belongs does not match the region to which the learned peer belongs,
   the route may be considered as the lowest preference.

   If the route verification result is invalid, the route can be
   consider as an invalid route and is not involved in route selection.
   This prevents routes belong to local region from being learned by
   external ASs and prevents possible route hijacking.

5.3.  Obtaining Region Information

   The region information and region confederation information can be
   obtained in either of the following ways:

   1) Obtained through the RP.  When the region information is
   registered through RPKI, it can be obtained through RP.

   2) Static configuration.  When RP is not ready, this can be achieved
   through manual configuration.

   Generally, the RPKI mode is recommended..

5.4.  Comparing with routing policy

   The verification here can also be implemented through routing
   policies.



Shen, et al.            Expires 3 September 2026                [Page 7]

Internet-Draft  Verification of Routes Using Region Auth      March 2026


   For region verification scenarios, regular expression-based
   policies，such as denying all routes whose origin AS is the local
   ISP's ASes, can be configured by the external peers to filter routes.

   However, in this mode, complex policies need to be configured based
   on the AS planning of the ISP.  In addition, these policies need to
   be integrated with existing routing policies, which is complex to
   use.

   The RPKI mechanism can be used to verify the area information
   obtained from the RP, which simplifies the deployment.

6.  Security Considerations

   NA

7.  Acknowledgements

   NA

8.  References

8.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>.

8.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-24, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-24>.

   [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>.







Shen, et al.            Expires 3 September 2026                [Page 8]

Internet-Draft  Verification of Routes Using Region Auth      March 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, <https://www.rfc-editor.org/info/rfc7908>.

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
   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










Shen, et al.            Expires 3 September 2026                [Page 9]

Internet-Draft  Verification of Routes Using Region Auth      March 2026


   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
   Email: chenshuanglong@huawei.com


























Shen, et al.            Expires 3 September 2026               [Page 10]
