idnits 2.17.1 draft-chen-grow-enhanced-as-loop-detection-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (September 10, 2020) is 1323 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) == Unused Reference: 'RFC4760' is defined on line 450, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track D. Ma 5 Expires: March 14, 2021 ZDNS 6 Y. Gu 7 S. Zhuang 8 H. Wang 9 Huawei 10 September 10, 2020 12 Enhanced AS-Loop Detection for BGP 13 draft-chen-grow-enhanced-as-loop-detection-05 15 Abstract 17 Misconfiguration and malicious manipulation of BGP AS_Path may lead 18 to route hijack. This document proposes to enhance the BGP [RFC4271] 19 Inbound/ Outbound route processing in the case of detecting an AS 20 loop. It is an enhancement to the current BGP's Inbound/Outbound 21 processing and can be implemented directly on the device, and this 22 document also proposes a centralized usecase. This could empower 23 networks to quickly and accurately figure out they're being 24 victimized. 26 Two options are proposed for the enhancement, a) a local check at the 27 device; b) data collection/analysis at the remote network controller/ 28 server. Both approaches are beneficial for route hijack detection. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 14, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Forged AS_PATH Examples . . . . . . . . . . . . . . . . . . . 4 73 3.1. AS Loop Detected at Inbound Processing . . . . . . . . . 4 74 3.2. AS Loop Detected at Outbound Processing . . . . . . . . . 5 75 4. Enhancement to BGP Inbound/Outbound Processing . . . . . . . 6 76 4.1. Enhancement for AS Loop Detected at Inbound Process . . . 6 77 4.2. Enhancement for AS Loop Detected at Outbound Process . . 7 78 5. Centralized AS-Loop Detection for BGP . . . . . . . . . . . . 7 79 5.1. BMP Support for Monitoring AS Path Looped Update Message 7 80 5.2. Application Example . . . . . . . . . . . . . . . . . . . 8 81 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The Border Gateway Protocol (BGP) [RFC4271], as an inter-autonomous 91 (AS) routing protocol, is used to exchange network reachability 92 information between BGP systems. BGP is widely used by Internet 93 Service Providers (ISPs) and large organizations. 95 As a distance-vector based protocol, BGP is used to exchange 96 reachable inter-AS routes, establish inter-AS paths, avoid routing 97 loops, and apply routing policies between ASs. BGP loop detection 98 mechanism is defined in section 9.1.2. of RFC4271: 100 ... 102 If the AS_PATH attribute of a BGP route contains an AS loop, the 103 BGP route should be excluded from the Phase 2 decision function. 104 AS loop detection is done by scanning the full AS path (as 105 specified in the AS_PATH attribute), and checking that the 106 autonomous system number of the local system does not appear in 107 the AS path. Operations of a BGP speaker that is configured to 108 accept routes with its own autonomous system number in the AS path 109 are outside the scope of this document. 111 ... 113 In ordinary BGP, every AS announces its route information with 114 different prefixes. However, its neighboring ASes cannot validate 115 this route information, but rather directly propagate it across the 116 Internet or simply discard AS-Loop routes directly. Obviously, this 117 weak trust model allows forged route announcement propagations and 118 rarely been found, which is a fundamental security weakness of BGP. 119 Forged routes, which can be generated by configuration errors or 120 malicious attacks, can lead to large-scale network connectivity 121 issues. 123 Some cases can be worse, hackers exploit this property of BGP to 124 achieve their ulterior motives. They can add some providers' AS 125 number into the forged AS-Path and attempt to make it look like the 126 route had passed through these ASNs, or perhaps they are there to 127 prevent those providers from carrying the route. These cases are 128 also being known As-Path Poisoning Attacks. 130 ASPA [I-D.ietf-sidrops-aspa-verification] can be used to verify the 131 AS_PATH attribute of routes advertised in the Border Gateway 132 Protocol, and it is a systematic deployment based on RPKI system. 133 This mechanism requires a series of infrastructure implementations. 135 This document proposes to enhance AS-Loop Detection for BGP Inbound/ 136 Outbound Route Processing when detecting AS loop in order to identify 137 possible BGP hijacks. It is an enhancement to the current BGP's 138 Inbound/Outbound processing and can be implemented directly on the 139 device, and this document also proposes a centralized usecase. This 140 could empower networks to quickly and accurately figure out they're 141 being victimized. 143 2. Terminology 145 The following terminology is used in this document. 147 AS: Autonomous System 149 ASPA: Autonomous System Provider Authorization 151 BGP: Border Gateway Protocol 153 BGP hijacking : is the illegitimate takeover of groups of IP 154 addresses by corrupting Internet routing tables maintained using the 155 Border Gateway Protocol (BGP). (Sometimes referred to as prefix 156 hijacking, route hijacking or IP hijacking) 158 EBGP: External BGP 160 ISP: Internet Service Provider 162 BMP: BGP Monitoring Protocol 164 ROA: Route Origin Authorization 166 3. Forged AS_PATH Examples 168 3.1. AS Loop Detected at Inbound Processing 170 o Forged Case 1: AS shown in Figure 1, an upstream AS of AS64596 171 forged a route with the ASN 64596 as the origin ASN in the AS- 172 Path. 174 o Forged Case 2: AS shown in Figure 1, an upstream AS of AS64596 175 forged a route with the ASN 64596 as the transit ASN in the AS- 176 Path. 178 AS-Loop-Detecting at this point 179 Discard AS-Loop Routes directly that contains AS64596 180 | 181 | x.y.z.0/24 182 v Origin AS 64600 183 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 184 From AS64597, To AS64596: 185 Normal Case: 186 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 188 Forged Case 1: 189 <-- x.y.z.0/24, AS-Path: 64597 64596 190 (Or: 64597 64598 64596 etc.) 192 Forged Case 2: 193 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 194 (Or: 64597 64596 64599 64600 etc.) 196 Figure 1: BGP Inbound Route Processing in AS64596 198 After receiving the above routes, AS64596 treats them as normal loop 199 routes during the loop detecting phase and discards them directly. 200 In most NOSes (Network Operation Systems), such rejected routes are 201 not logged and only visible by putting the router into debugging 202 mode. If the AS64596 is slightly enhanced, it can find that someone 203 has faked himself, which may cause unnecessary trouble for himself. 205 3.2. AS Loop Detected at Outbound Processing 207 Split-Horizon for EBGP is an optional function that a BGP sender will 208 not advertise any routes that were previously received from that same 209 AS. In some current implementation, the BGP outbound route 210 processing step will simply discard the route if AS-Loop being 211 detected. 213 o Forged Case 3: AS shown in Figure 2, an upstream AS of AS64597 214 forged a route with the ASN 64596 as the origin ASN in the AS- 215 Path. 217 o Forged Case 4: AS shown in Figure 2, an upstream AS of AS64597 218 forged a route with the ASN 64596 as the transit ASN in the AS- 219 Path. 221 Split-Horizon Enable & AS-Loop-Detecting at this point 222 Discard AS-Loop Routes directly if sending AS-Path contains AS64596 223 | 224 | x.y.z.0/24 225 v Origin AS 64600 226 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 227 From AS64597, To AS64596: 228 Normal Case: 229 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 231 Forged Case 3: 232 <-- x.y.z.0/24, AS-Path: 64597 64596 233 (Or: 64597 64598 64596 etc.) 235 Forged Case 4: 236 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 237 (Or: 64597 64596 64599 64600 etc.) 239 Figure 2: BGP Outbound Route Processing in AS64597 241 When sending the above routes, AS64597 treats them as normal loop 242 routes and discards them directly. If AS64597 is slightly enhanced, 243 it can find that someone has faked AS64596, which may cause large- 244 scale network connectivity problems. 246 4. Enhancement to BGP Inbound/Outbound Processing 248 4.1. Enhancement for AS Loop Detected at Inbound Process 250 Currently, ROV [RFC6811] and ASPA verification 251 [I-D.ietf-sidrops-aspa-verification] can be adopted for BGP leak/ 252 hijack detection. However, for the forged case 1&2, the conventional 253 BGP inbound process would simply discard the routes with AS loop 254 before any further leak/hajack detection. 256 This document suggests further analysis of such routes. The analysis 257 may include mechanisms that apply to normal routes for hijack 258 detection, such as ROV, ASPA and so on. The detailed analyzing 259 mechanisms as well as the corresponding actions w.r.t. the analysis 260 are outside the scope of this document. Two options of where the 261 analysis of the inbound processing enhancement takes place is 262 proposed. 264 o Option 1: Analyze the routes with AS loop based on local database. 266 o Option 2: Collect the routes with AS loop with BMP and analyze 267 them at the remote controller/server. 269 4.2. Enhancement for AS Loop Detected at Outbound Process 271 Currently, the egress ROV can be adopted for BGP hijack detection. 272 However, for forged case 3&4, when eBGP Split-Horizon is enabled, the 273 routes with AS loop could possibly be discarded before any hijack 274 detection. 276 This document suggests further analysis of such routes. The analysis 277 may include mechanisms that apply to normal routes for hijack 278 detection, such as egress ROV, ASPA and so on. The detailed 279 analyzing mechanisms as well as the corresponding actions w.r.t. the 280 analysis are outside the scope of this document. 282 Two options of where the analysis of the outbound processing 283 enhancement takes place is proposed. 285 o Option 1: Analyze the routes with AS loop based on local database. 287 o Option 2: Collect the routes with AS loop with BMP and analyze 288 them at the remote controller/server. 290 5. Centralized AS-Loop Detection for BGP 292 Considering the challenges facing the existing approaches, this 293 section proposes a centralized method. It utilizes the BGP 294 Monitoring Protocol (BMP) to convey the AS Path Looped Update message 295 from the monitored device to the BMP server to realize centralized 296 attack detection. 298 BMP is currently deployed by OTT and Carriers to monitor the BGP 299 routes, such as monitoring BGP Adj-RIB-In using the process defined 300 in RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the 301 process defined in RFC8761 [RFC8671]. This document extends Route 302 Mirroring message to mirror AS Path Looped update message to the BMP 303 Server. 305 5.1. BMP Support for Monitoring AS Path Looped Update Message 307 Per RFC7854, Route Mirroring messages can be used to mirror the 308 messages that have been treated-as-withdraw [RFC7606], for debugging 309 purposes. This document extends Route Mirroring message to mirror AS 310 Path Looped update message to the BMP Server. 312 This document adds a new code for Type 1 Information TLV: 314 o Code = TBD: AS Path Looped. The BGP Message TLV occurs in the 315 Route Mirroring message and whose loop includes the local AS. 317 Following the common BMP header and per-peer header is an Information 318 TLV (Type = 1) with Code = TBD: AS Path Looped, and then a BGP 319 Message TLV (Type = 0) contain an AS Path Looped Update Message. 321 +---------------------------------------------------------------+ 322 | Common BMP Header (Message Type = 6) | 323 +---------------------------------------------------------------+ 324 | Per peer Header | 325 +---------------------------------------------------------------+ 326 | Information TLV (Type = 1) with Code = TBD: AS Path Looped | 327 +---------------------------------------------------------------+ 328 | BGP Message TLV (Type = 0) | 329 +---------------------------------------------------------------+ 331 Figure 3: AS Path Looped Update Message Carrying in the Route 332 Mirroring Message 334 5.2. Application Example 336 This section describe a centralized application example. As shown in 337 Figure 4, when receiving the routes from AS64597, AS64596 should 338 check whether its own AS number is already in the AS-Path, If yes, it 339 further encapsulate the AS Path Looped Update Message in the Route 340 Mirroring message and sends the Route Mirroring message to the BMP 341 Server. 343 The Analyzer gets the AS Path Looped Update Messages from the BMP 344 Server and further processes them. 346 +------------+ 347 | BMP server | 348 | + | 349 | Analyzer | 350 +------+-----+ 351 BMP Mirroring Message: \ 352 AS Path Looped Update Message\to BMP Server 353 \ 354 \ 355 ********************|**** 356 * | * 357 * AS64596 | * "AS64597 Send Routes 358 * | * <----- to AS64596" 359 +-------+ * +---+ +---+ * +-------+ 360 +AS64595+-------+ R1+---------+ R2|-----+AS64597+---64598 64599 64600 361 +-------+ * +-+-+\ +---+ * +-------+ 362 * | \\ // |\ * 363 * | \\// | \ * 364 * | //\ | \ * +-------+ 365 * | // \\ | \+------+AS64593+ 366 * | / \ | * +-------+ 367 +-------+ * +-+-+ +-+-+ * +-------+ 368 +AS64594+----+--+ R3+---------+ R4+---------+AS64592+ 369 +-------+ * +---+ +---+ * +-------+ 370 * * 371 ************************* 373 Figure 4: Centralized AS-Loop Detection 375 From the perspective of the local AS, it can manage/hold the AS- 376 relationship database between the local AS and each of its 377 neighboring ASs (such as C2P, P2P, P2C, etc.). 379 +--------------------------------------------------+ 380 | Neighboring AS | AS-relationship to AS64596 | 381 +--------------------------------------------------+ 382 | 64592 | P2P | 383 +--------------------------------------------------+ 384 | 64593 | S2S | 385 +--------------------------------------------------+ 386 | 64594 | C2P | 387 +--------------------------------------------------+ 388 | 64595 | P2C | 389 +--------------------------------------------------+ 390 | 64597 | P2P | 391 +--------------------------------------------------+ 393 Figure 5: AS64596's AS-Relationship Database 395 When AS 64596 is listed as transit AS in the AS-Path, for example, 396 AS-Path looks like the following form AS64596's perspective: 398 (possible other ASes), left AS, local AS(64596), right AS, (possible 399 other ASes) 401 At this point, AS64596's Analyzer can lookup the local resource 402 database and check whether there is a real AS relationship between 403 the local AS and the left AS and the right AS. 405 6. Benefits 407 After the enhancements of the AS Loop Detection for BGP Inbound/ 408 Outbound Route Processing are added, the stability and security of 409 the network can be improved. 411 7. Acknowledgements 413 The authors would like to acknowledge the review and inputs from Gang 414 Yan, Zhenbin Li, Aijun Wang, Jeff Haas, Robert Raszuk, Chris Morrow, 415 Alexander Asimov, Ruediger Volk, Jescia Chen and the working group. 417 8. IANA Considerations 419 This document defines one type for information carried in the Route 420 Mirroring Information (Section 4.7 of RFC7854) code: 422 o Code = TBD: AS Path Looped. 424 9. Security Considerations 426 This document does not change the underlying security issues in the 427 BGP protocol. It however, does provide an additional mechanism to 428 protect against attacks based on the forged AS-Path in the BGP 429 routes. 431 10. Normative References 433 [I-D.ietf-sidrops-aspa-verification] 434 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 435 Snijders, "Verification of AS_PATH Using the Resource 436 Certificate Public Key Infrastructure and Autonomous 437 System Provider Authorization", draft-ietf-sidrops-aspa- 438 verification-04 (work in progress), March 2020. 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 446 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 447 DOI 10.17487/RFC4271, January 2006, 448 . 450 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 451 "Multiprotocol Extensions for BGP-4", RFC 4760, 452 DOI 10.17487/RFC4760, January 2007, 453 . 455 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 456 Austein, "BGP Prefix Origin Validation", RFC 6811, 457 DOI 10.17487/RFC6811, January 2013, 458 . 460 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 461 Patel, "Revised Error Handling for BGP UPDATE Messages", 462 RFC 7606, DOI 10.17487/RFC7606, August 2015, 463 . 465 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 466 Monitoring Protocol (BMP)", RFC 7854, 467 DOI 10.17487/RFC7854, June 2016, 468 . 470 [RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 471 Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring 472 Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 473 2019, . 475 Authors' Addresses 477 Huanan Chen 478 China Telecom 479 109, West Zhongshan Road, Tianhe District 480 Guangzhou 510000 481 China 483 Email: chenhuan6@chinatelecom.cn 485 Di Ma 486 ZDNS 487 4 South 4th St. Zhongguancun 488 Beijing, Haidian 489 China 491 Email: madi@zdns.cn 493 Yunan Gu 494 Huawei 495 Huawei Bld., No.156 Beiqing Rd. 496 Beijing 100095 497 China 499 Email: guyunan@huawei.com 501 Shunwan Zhuang 502 Huawei 503 Huawei Bld., No.156 Beiqing Rd. 504 Beijing 100095 505 China 507 Email: zhuangshunwan@huawei.com 508 Haibo Wang 509 Huawei 510 Huawei Bld., No.156 Beiqing Rd. 511 Beijing 100095 512 China 514 Email: rainsword.wang@huawei.com