idnits 2.17.1 draft-chen-grow-enhanced-as-loop-detection-04.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 (March 09, 2020) is 1510 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 448, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-03 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: September 10, 2020 ZDNS 6 Y. Gu 7 S. Zhuang 8 H. Wang 9 Huawei 10 March 09, 2020 12 Enhanced AS-Loop Detection for BGP 13 draft-chen-grow-enhanced-as-loop-detection-04 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 September 10, 2020. 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 Normal Case: 185 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 187 Forged Case 1: 188 <-- x.y.z.0/24, AS-Path: 64597 64596 189 (Or: 64597 64598 64596 etc.) 191 Forged Case 2: 192 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 193 (Or: 64597 64596 64599 64600 etc.) 195 Figure 1: BGP Inbound Route Processing 197 After receiving the above routes, AS64596 treats them as normal loop 198 routes during the loop detecting phase and discards them directly. 199 In most NOSes (Network Operation Systems), such rejected routes are 200 not logged and only visible by putting the router into debugging 201 mode. If the AS64596 is slightly enhanced, it can find that someone 202 has faked himself, which may cause unnecessary trouble for himself. 204 3.2. AS Loop Detected at Outbound Processing 206 Split-Horizon for EBGP is an optional function that a BGP sender will 207 not advertise any routes that were previously received from that same 208 AS. In some current implementation, the BGP outbound route 209 processing step will simply discard the route if AS-Loop being 210 detected. 212 o Forged Case 3: AS shown in Figure 2, an upstream AS of AS64597 213 forged a route with the ASN 64596 as the origin ASN in the AS- 214 Path. 216 o Forged Case 4: AS shown in Figure 2, an upstream AS of AS64597 217 forged a route with the ASN 64596 as the transit ASN in the AS- 218 Path. 220 Split-Horizon Enable & AS-Loop-Detecting at this point 221 Discard AS-Loop Routes directly if sending AS-Path contains AS64596 222 | 223 | x.y.z.0/24 224 v Origin AS 64600 225 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 226 Normal Case: 227 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 229 Forged Case 3: 230 <-- x.y.z.0/24, AS-Path: 64597 64596 231 (Or: 64597 64598 64596 etc.) 233 Forged Case 4: 234 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 235 (Or: 64597 64596 64599 64600 etc.) 237 Figure 2: BGP Outbound Route Processing 239 When sending the above routes, AS64597 treats them as normal loop 240 routes and discards them directly. If AS64597 is slightly enhanced, 241 it can find that someone has faked AS64596, which may cause large- 242 scale network connectivity problems. 244 4. Enhancement to BGP Inbound/Outbound Processing 246 4.1. Enhancement for AS Loop Detected at Inbound Process 248 Currently, ROV [RFC6811] and ASPA verification 249 [I-D.ietf-sidrops-aspa-verification] can be adopted for BGP leak/ 250 hijack detection. However, for the forged case 1&2, the conventional 251 BGP inbound process would simply discard the routes with AS loop 252 before any further leak/hajack detection. 254 This document suggests further analysis of such routes. The analysis 255 may include mechanisms that apply to normal routes for hijack 256 detection, such as ROV, ASPA and so on. The detailed analyzing 257 mechanisms as well as the corresponding actions w.r.t. the analysis 258 are outside the scope of this document. Two options of where the 259 analysis of the inbound processing enhancement takes place is 260 proposed. 262 o Option 1: Analyze the routes with AS loop based on local database. 264 o Option 2: Collect the routes with AS loop with BMP and analyze 265 them at the remote controller/server. 267 4.2. Enhancement for AS Loop Detected at Outbound Process 269 Currently, the egress ROV can be adopted for BGP hijack detection. 270 However, for forged case 3&4, when eBGP Split-Horizon is enabled, the 271 routes with AS loop could possibly be discarded before any hijack 272 detection. 274 This document suggests further analysis of such routes. The analysis 275 may include mechanisms that apply to normal routes for hijack 276 detection, such as egress ROV, ASPA and so on. The detailed 277 analyzing mechanisms as well as the corresponding actions w.r.t. the 278 analysis are outside the scope of this document. 280 Two options of where the analysis of the outbound processing 281 enhancement takes place is proposed. 283 o Option 1: Analyze the routes with AS loop based on local database. 285 o Option 2: Collect the routes with AS loop with BMP and analyze 286 them at the remote controller/server. 288 5. Centralized AS-Loop Detection for BGP 290 Considering the challenges facing the existing approaches, this 291 section proposes a centralized method. It utilizes the BGP 292 Monitoring Protocol (BMP) to convey the AS Path Looped Update message 293 from the monitored device to the BMP server to realize centralized 294 attack detection. 296 BMP is currently deployed by OTT and Carriers to monitor the BGP 297 routes, such as monitoring BGP Adj-RIB-In using the process defined 298 in RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the 299 process defined in draft-ietf-grow-bmp-adj-rib-out [RFC8671]. This 300 document extends Route Mirroring message to mirror AS Path Looped 301 update message to the BMP Server. 303 5.1. BMP Support for Monitoring AS Path Looped Update Message 305 Per RFC7854, Route Mirroring messages can be used to mirror the 306 messages that have been treated-as-withdraw [RFC7606], for debugging 307 purposes. This document extends Route Mirroring message to mirror AS 308 Path Looped update message to the BMP Server. 310 This document adds a new code for Type 1 Information TLV: 312 o Code = TBD: AS Path Looped. The BGP Message TLV occurs in the 313 Route Mirroring message and whose loop includes the local AS. 315 Following the common BMP header and per-peer header is an Information 316 TLV (Type = 1) with Code = TBD: AS Path Looped, and then a BGP 317 Message TLV (Type = 0) contain an AS Path Looped Update Message. 319 +---------------------------------------------------------------+ 320 | Common BMP Header (Message Type = 6) | 321 +---------------------------------------------------------------+ 322 | Per peer Header | 323 +---------------------------------------------------------------+ 324 | Information TLV (Type = 1) with Code = TBD: AS Path Looped | 325 +---------------------------------------------------------------+ 326 | BGP Message TLV (Type = 0) | 327 +---------------------------------------------------------------+ 329 Figure 3: AS Path Looped Update Message Carrying in the Route 330 Mirroring Message 332 5.2. Application Example 334 This section describe a centralized application example. As shown in 335 Figure 4, when receiving the routes from AS64597, AS64596 should 336 check whether its own AS number is already in the AS-Path, If yes, it 337 further encapsulate the AS Path Looped Update Message in the Route 338 Mirroring message and sends the Route Mirroring message to the BMP 339 Server. 341 The Analyzer gets the AS Path Looped Update Messages from the BMP 342 Server and further processes them. 344 +------------+ 345 | BMP server | 346 | + | 347 | Analyzer | 348 +------+-----+ 349 BMP Mirroring Message: \ 350 AS Path Looped Update Message\to BMP Server 351 \ 352 \ 353 ********************|**** 354 * | * 355 * AS64596 | * "AS64597 Send Routes 356 * | * <----- to AS64596" 357 +-------+ * +---+ +---+ * +-------+ 358 +AS64595+-------+ R1+---------+ R2|-----+AS64597+---64598 64599 64600 359 +-------+ * +-+-+\ +---+ * +-------+ 360 * | \\ // |\ * 361 * | \\// | \ * 362 * | //\ | \ * +-------+ 363 * | // \\ | \+------+AS64593+ 364 * | / \ | * +-------+ 365 +-------+ * +-+-+ +-+-+ * +-------+ 366 +AS64594+----+--+ R3+---------+ R4+---------+AS64592+ 367 +-------+ * +---+ +---+ * +-------+ 368 * * 369 ************************* 371 Figure 4: Centralized AS-Loop Detection 373 From the perspective of the local AS, it can manage/hold the AS- 374 relationship database between the local AS and each of its 375 neighboring ASs (such as C2P, P2P, P2C, etc.). 377 +--------------------------------------------------+ 378 | Neighboring AS | AS-relationship to AS64596 | 379 +--------------------------------------------------+ 380 | 64592 | P2P | 381 +--------------------------------------------------+ 382 | 64593 | S2S | 383 +--------------------------------------------------+ 384 | 64594 | C2P | 385 +--------------------------------------------------+ 386 | 64595 | P2C | 387 +--------------------------------------------------+ 388 | 64597 | P2P | 389 +--------------------------------------------------+ 391 Figure 5: AS64596's AS-Relationship Database 393 When AS 64596 is listed as transit AS in the AS-Path, for example, 394 AS-Path looks like the following form AS64596's perspective: 396 (possible other ASes), left AS, local AS(64596), right AS, (possible 397 other ASes) 399 At this point, AS64596's Analyzer can lookup the local resource 400 database and check whether there is a real AS relationship between 401 the local AS and the left AS and the right AS. 403 6. Benefits 405 After the enhancements of the AS Loop Detection for BGP Inbound/ 406 Outbound Route Processing are added, the stability and security of 407 the network can be improved. 409 7. Acknowledgements 411 The authors would like to acknowledge the review and inputs from Gang 412 Yan, Zhenbin Li, Aijun Wang, Jeff Haas, Robert Raszuk, Chris Morrow, 413 Alexander Asimov, Ruediger Volk, Jescia Chen and the working group. 415 8. IANA Considerations 417 This document defines one type for information carried in the Route 418 Mirroring Information (Section 4.7 of RFC7854) code: 420 o Code = TBD: AS Path Looped. 422 9. Security Considerations 424 This document does not change the underlying security issues in the 425 BGP protocol. It however, does provide an additional mechanism to 426 protect against attacks based on the forged AS-Path in the BGP 427 routes. 429 10. Normative References 431 [I-D.ietf-sidrops-aspa-verification] 432 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 433 Snijders, "Verification of AS_PATH Using the Resource 434 Certificate Public Key Infrastructure and Autonomous 435 System Provider Authorization", draft-ietf-sidrops-aspa- 436 verification-03 (work in progress), November 2019. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 444 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 445 DOI 10.17487/RFC4271, January 2006, 446 . 448 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 449 "Multiprotocol Extensions for BGP-4", RFC 4760, 450 DOI 10.17487/RFC4760, January 2007, 451 . 453 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 454 Austein, "BGP Prefix Origin Validation", RFC 6811, 455 DOI 10.17487/RFC6811, January 2013, 456 . 458 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 459 Patel, "Revised Error Handling for BGP UPDATE Messages", 460 RFC 7606, DOI 10.17487/RFC7606, August 2015, 461 . 463 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 464 Monitoring Protocol (BMP)", RFC 7854, 465 DOI 10.17487/RFC7854, June 2016, 466 . 468 [RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 469 Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring 470 Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 471 2019, . 473 Authors' Addresses 475 Huanan Chen 476 China Telecom 477 109, West Zhongshan Road, Tianhe District 478 Guangzhou 510000 479 China 481 Email: chenhuan6@chinatelecom.cn 483 Di Ma 484 ZDNS 485 4 South 4th St. Zhongguancun 486 Beijing, Haidian 487 China 489 Email: madi@zdns.cn 491 Yunan Gu 492 Huawei 493 Huawei Bld., No.156 Beiqing Rd. 494 Beijing 100095 495 China 497 Email: guyunan@huawei.com 499 Shunwan Zhuang 500 Huawei 501 Huawei Bld., No.156 Beiqing Rd. 502 Beijing 100095 503 China 505 Email: zhuangshunwan@huawei.com 506 Haibo Wang 507 Huawei 508 Huawei Bld., No.156 Beiqing Rd. 509 Beijing 100095 510 China 512 Email: rainsword.wang@huawei.com