idnits 2.17.1 draft-shen-sidrops-region-verification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2021) is 1024 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDROPS C. Shen 3 Internet-Draft W. Yu 4 Intended status: Standards Track CAICT 5 Expires: January 9, 2022 Y. Liu 6 China Mobile 7 H. Wang 8 S. Chen 9 Huawei Technologies 10 July 08, 2021 12 Verification of Routes Using Region Authorization 13 draft-shen-sidrops-region-verification-00 15 Abstract 17 BGP routing security is becoming a major issue that affects the 18 normal running of Internet services. Currently, there are many 19 solutions, including ROA authentication and ASPA authentication, to 20 prevent route source hijacking, path hijacking, and route leaking. 21 However, on an actual network, large ISPs with multiple ASes can use 22 carefully constructed routes to bypass ROA and ASPA authentication to 23 attack the target network. 25 This document defines an region-based authentication method for large 26 ISPs with many ASes to prevent traffic hijacking within ISPs. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Route hijacking risk within a single ISP . . . . . . . . 3 71 3.2. Route hijacking risk between multiple ISPs . . . . . . . 4 72 4. Region based verification . . . . . . . . . . . . . . . . . . 6 73 4.1. Singe region verification . . . . . . . . . . . . . . . . 6 74 4.2. Multiple region verification . . . . . . . . . . . . . . 6 75 4.3. Obtaining Region Information . . . . . . . . . . . . . . 7 76 4.4. Comparing with routing policy . . . . . . . . . . . . . . 7 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 7.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 The design of the Border Gateway Protocol (BGP) lacks a mechanism to 87 validate BGP attributes, which is prone to BGP hijacking and BGP 88 route leaks [RFC7908]. 90 [RFC6811] defines a method for verifying the origin of BGP prefixes, 91 which can resolve the most common source AS hijacking. 92 [I-D.ietf-sidrops-aspa-verification] defines an AS-pairs based 93 authentication method to resolve AS-Path hijacking and route leaking. 95 However, even if these two technologies are deployed on large ISP 96 networks with many ASs, there is still a risk of being attacked by 97 carefully constructed path hijacking. 99 2. Terminology 101 OV: Origin Validation 103 RPKI: Resource Public Key Infrastructure 105 RP: Relying Party 107 3. Problem Statement 109 Currently, some large ISPs have many public ASes to facilitate 110 management. In these ISPs, only a few ASes are used to connect to 111 external ISPs. However, the sub-ASes of these ISPs also exchange 112 routes to provide services for different customers. Therefore, the 113 route access between these sub-ASes may be attacked by carefully 114 constructed as-path. 116 3.1. Route hijacking risk within a single ISP 118 /--------------------------\ 119 | ISP1 | 120 +----+ | ,.., | 121 |user| | / \ | 122 | |-----| AS | | 123 +----+ | |65002 - | 124 | \ / `. | 125 | `'-` \ ,.., | /--------\ 126 | `. / \ | | ISP10 | 127 | ' AS --------- | 128 | ,65001 | | | AS65500| 129 | / \ / | | | 130 | / `'-` | \--------/ 131 | ,.., / | 132 | / \ / | 133 +----+ | | AS / | 134 |serv-------|65003 | | 135 |er | | \ / | 136 +----+ | `'-` | 137 | | 138 \--------------------------/ 139 Figure 1 Route hijacking risk within a single ISP 141 As shown in the Figure 1. ISP1 has AS65001, AS65002, and AS65003 and 142 connects to an external ISP, such as AS65500. There is a server 143 connect to the AS65003, and a user connecte to the AS65002. AS65003 144 advertises the server's route to AS65002, and AS65002 uses the route 145 to provide services for users. 147 After the AS65500 obtains the route for the server, it can spoof the 148 route and change the source AS to AS65003. In this way, the spoofed 149 route is advertised to AS65001 with AS-Path AS65500 AS65003. AS65001 150 selects routes between the routes advertised by AS65003 and AS65500. 151 Therefore, AS65001 may preferentially select the forged routes of 152 AS65500. As a result, subsequent traffic from users to the server is 153 hijacked to AS65500. 155 IIn actual deployment, to facilitate traffic adjustment, the mask of 156 the address in the ROA database registered by ISP1 may be in a 157 certain range. In this case, the AS65500 can more easily hijack 158 traffic by using more specific prefixes and spoofing the source AS. 160 The scenario described here can be prevented by ASPA because the AS 161 pair (AS65500,AS65003) does not exist.. 163 3.2. Route hijacking risk between multiple ISPs 164 /---------------------\ /--------------------\ 165 | ISP1 | | ISP2 | 166 +----+ | ,-. | | ,-. | 167 |user| | / \ | | / \ | 168 | |-----| AS | | | | AS | | 169 +----+ | |65002\ | | |65106| | 170 | \ / \ ,-. | | ,-. .\ / | 171 | '-' \ / \ | | / \ ` '-' | 172 | '| AS | | | | AS |-` | 173 | ,-. .|65001------------|65104| ,-. | 174 | / \ ` \ / | | \ / `. / \ | +----+ 175 | | AS -` '\' | | '\' '| AS | | |serv| 176 | |65003| \ | | , |65105|-----|er | 177 | \ / , | | / \ / | +----+ 178 | '-' \ | | / '-' | 179 \------------------\--/ \-/------------------/ 180 \ .' 181 \ / 182 \ / 183 /------\---/--------\ 184 | '.-, | 185 | / \ | 186 | | AS | | 187 | |65500 | | 188 | \ / | 189 | `'-` | 190 | ISP3 | 191 \-------------------/ 192 Figure 2 Route hijacking risk between multiple ISPs 194 As shown in Figure 2. ISP1 has AS65001, AS65002, and AS65003 and 195 connects to external ISPs, such as AS65500 and ISP2's AS65104. ISP2 196 has AS65104, AS65105, and AS65106, and connects to external ISPs such 197 as AS65500 and ISP1's AS65001. There is a server connect to AS65105, 198 and a user connect to AS65002. AS65105 advertises the server's route 199 to AS65002 through the BGP peer. AS65002 then provides services for 200 users. 202 The AS65500 can also obtain the route for the server from AS65104. 203 The AS65500 can spoof the route of the server and change the source 204 AS to AS65105. In this way, the AS65500 constructs a more specific 205 prefix, which AS-Path is AS65500 AS65104 AS65105, and advertises the 206 route to AS65001. The traffic from the user to the server will be 207 hijacked to AS65500. 209 In this scenario it also can't be prevented by ASPA. 211 4. Region based verification 213 To solve this problem, we expect to use a region-based verification 214 method. This method is applicable to large ISPs with multiple ASes. 215 In addition to OV verification, region-based verification is 216 performed to prevent the attack scenarios mentioned in section 3. 218 4.1. Singe region verification 220 As shown in Figure 1, ISP1 can be set to area 1, including AS65001, 221 AS65002, and AS65003. 223 When a device learns a route, it will verifie whether the route is a 224 local region route based on basic OV verification. 226 The verification process is as follows: 228 1) Perform OV verification on the route. If the OV verification 229 result is valid, then perform area verification. 231 2) Check whether the route's origin AS is belong to local region. 233 3) If not, it indicates that the route is not a local region route. 234 No additional verification is required in single region scenarios.. 236 4) If the route's origin AS is belong to local region, check whether 237 the peer that learns the route is belong to local region. 239 5) If the peer that learns a route is not belong to local region, the 240 route verification result is invalid. 242 If the route verification result is invalid, the route can be 243 consider as an invalid route and is not involved in route selection. 244 This prevents routes belong to local region from being learned by 245 external ASs and prevents possible route hijacking. 247 4.2. Multiple region verification 249 For the case of Figure 2, we can set region confederations. ISP1 is 250 set to region 1, including AS65001, AS65002, and AS65003. ISP2 is 251 set to region 2, including AS65104, AS65105, and AS6. In addition, 252 the region of ISP1 and ISP2 form a regional confederation, which is 253 set to regional confederation 1. 255 The verification process is as follows: 257 1) First, perform the step of region verification. After single 258 region verification step 2, if the route's origin AS is not belong to 259 local region, then check whether the route belongs to the local 260 confederation. 262 2) If the route belongs to the local confederation, check whether the 263 peer that learned the route is belong to the local confederation. 265 3) If the peer is not belong to the local confederation, the route 266 verification result is invalid. 268 4) Optionally, we may further check whether the peer is the region to 269 which the route belongs. If the region to which the route belongs 270 does not match the region to which the learned peer belongs, we may 271 further consider that route with lowest preference. Of course, we 272 don't usually need to do that. 274 If the route verification result is invalid, the route can be 275 consider as an invalid route and is not involved in route selection. 276 This prevents routes belong to local region from being learned by 277 external ASs and prevents possible route hijacking. 279 4.3. Obtaining Region Information 281 The region information and region confederation information can be 282 obtained in either of the following ways: 284 1) Obtained through the RP. You can register region data with the 285 RPKI and download the region infomation through the RP. 287 2) Static configuration. When RP is not ready, we may also use 288 static configuration to implement. You can specify an region, its 289 ASes, and the confederation information to which the region belongs. 291 Generally, the RPKI mode is recommended.. 293 4.4. Comparing with routing policy 295 The verification here can be implemented through routing policies. 297 For example, for region verification, you can configure policies and 298 AS regular expressions. For peers connected to ISP's external ASes , 299 you can configure policies to deny all routes whose origin AS is the 300 local ISP's ASes. 302 However, in this mode, complex policies need to be configured based 303 on the AS planning of the ISP. In addition, these policies need to 304 be integrated with existing routing policies, which is complex to 305 use. 307 The RPKI mechanism can be used to verify the area information 308 obtained from the RP, which simplifies the deployment. 310 5. Security Considerations 312 NA 314 6. Acknowledgements 316 NA 318 7. References 320 7.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 7.2. Informative References 329 [I-D.ietf-sidrops-aspa-verification] 330 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 331 Snijders, "Verification of AS_PATH Using the Resource 332 Certificate Public Key Infrastructure and Autonomous 333 System Provider Authorization", draft-ietf-sidrops-aspa- 334 verification-07 (work in progress), February 2021. 336 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 337 Austein, "BGP Prefix Origin Validation", RFC 6811, 338 DOI 10.17487/RFC6811, January 2013, 339 . 341 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 342 and B. Dickson, "Problem Definition and Classification of 343 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 344 2016, . 346 Authors' Addresses 348 Chen Shen 349 CAICT 350 No.52, Hua Yuan Bei Road 351 Beijing 100191 352 China 354 Email: shenchen@caict.ac.cn 355 Wenyan Yu 356 CAICT 357 No.52, Hua Yuan Bei Road 358 Beijing 100191 359 China 361 Email: yuwenyan@caict.ac.cn 363 Yisong Liu 364 China Mobile 365 32 Xuanwumenxi Ave. 366 Beijing 100032 367 China 369 Email: liuyisong@chinamobile.com 371 Haibo Wang 372 Huawei Technologies 373 Huawei Campus, No. 156 Beiqing Road 374 Beijing 100095 375 China 377 Email: rainsword.wang@huawei.com 379 Shuanglong Chen 380 Huawei Technologies 381 Huawei Campus, No. 156 Beiqing Road 382 Beijing 100095 383 China 385 Email: chenshuanglong@huawei.com