idnits 2.17.1 draft-chen-grow-enhanced-as-loop-detection-01.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 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (April 2, 2019) is 1851 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4760' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC7854' is defined on line 369, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 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: Best Current Practice D. Ma 5 Expires: October 4, 2019 ZDNS 6 Y. Gu 7 S. Zhuang 8 H. Wang 9 Huawei 10 April 2, 2019 12 Enhanced AS-Loop Detection for BGP 13 draft-chen-grow-enhanced-as-loop-detection-01 15 Abstract 17 This document proposes to enhance AS-Loop Detection for BGP Inbound/ 18 Outbound Route Processing. This could empower networks to quickly 19 and accurately figure out they're being victimized. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 4, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Enhanced AS-Loop Detection for BGP Inbound Route Processing . 5 64 4. Enhanced AS-Loop Detection for BGP Outbound Route Processing 7 65 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The Border Gateway Protocol (BGP) [RFC4271], as an inter-Autonomous 75 (AS) routing protocol, is used to exchange network reachability 76 information between BGP systems. BGP is widely used by Internet 77 Service Providers (ISPs) and large organizations. 79 BGP is used to exchange reachable inter-AS routes, establish inter-AS 80 paths, avoid routing loops, and apply routing policies between ASs. 81 BGP loop detection mechanism is defined in section 9.1.2. of RFC4271: 83 ... 85 If the AS_PATH attribute of a BGP route contains an AS loop, the 86 BGP route should be excluded from the Phase 2 decision function. 87 AS loop detection is done by scanning the full AS path (as 88 specified in the AS_PATH attribute), and checking that the 89 autonomous system number of the local system does not appear in 90 the AS path. Operations of a BGP speaker that is configured to 91 accept routes with its own autonomous system number in the AS path 92 are outside the scope of this document. 94 ... 96 In ordinary BGP, every AS announces its route information with 97 different prefixes. However, its neighboring ASes cannot validate 98 this route information, but rather directly propagate it across the 99 Internet or simply discard AS-Loop routes directly. Obviously, this 100 weak trust model allows forged route announcement propagations and 101 rarely been found, which is a fundamental security weakness of BGP. 102 Forged routes, which can be generated by configuration errors or 103 malicious attacks, can cause large-scale network connectivity 104 problems. 106 Some cases can be worse, hackers exploit this property of BGP to 107 achieve their ulterior motives. They can add some providers' AS 108 number into the forged AS-Path and attempt to make it look like the 109 route had passed through these ASNs, or perhaps they are there to 110 prevent those providers from carrying the route. 112 For example, the cases shown in Figure 1. 114 o Forged Case 1: One upstream ISP of AS64596 forged a route with the 115 ASN 64596 as the origin ASN in the AS-Path. 117 o Forged Case 2: One upstream ISP of AS64596 forged a route with the 118 ASN 64596 as the transit ASN in the AS-Path. 120 After receiving the above routes, AS64596 treats them as normal loop 121 routes during the loop detecting phase and discards them directly. 122 In most NOSes (Netwok Operation Systems), such rejected routes are 123 not logged and only visable by puuting the router into debugging 124 mode. If the AS64596 is slightly enhanced, it can find that someone 125 has faked himself, which may cause unnecessary trouble for himself. 127 AS-Loop-Detecting at this point 128 Discard AS-Loop Routes directly that contains AS64596 129 | 130 | 131 v x.y.z.0/24 Origin AS 64600 132 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 133 Normal Case: 134 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 136 Forged Case 1: 137 <-- x.y.z.0/24, AS-Path: 64597 64596 138 (Or: 64597 64598 64596 etc.) 140 Forged Case 2: 141 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 142 (Or: 64597 64596 64599 64600 etc.) 144 Figure 1: BGP Inbound Route Processing 146 Split-Horizon for EBGP is an optional function that a BGP sender will 147 not advertise any routes that were previously received from that same 148 AS. In some current implementation, the BGP outbound route 149 processing step will simply discard the route if AS-Loop being 150 detected. 152 For example, the cases shown in Figure 1. 154 o Forged Case 1: One upstream ISP of AS64597 forged a route with the 155 ASN 64596 as the origin ASN in the AS-Path. 157 o Forged Case 2: One upstream ISP of AS64597 forged a route with the 158 ASN 64596 as the transit ASN in the AS-Path. 160 When sending the above routes, AS64597 treats them as normal loop 161 routes and discards them directly. If AS64597 is slightly enhanced, 162 it can find that someone has faked AS64596, which may cause large- 163 scale network connectivity problems. 165 Split-Horizon Enable & AS-Loop-Detecting at this point 166 Discard AS-Loop Routes directly if sending AS-Path contains AS64596 167 | 168 | 169 v x.y.z.0/24 Origin AS 64600 170 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 171 Normal Case: 172 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 174 Forged Case 1: 175 <-- x.y.z.0/24, AS-Path: 64597 64596 176 (Or: 64597 64598 64596 etc.) 178 Forged Case 2: 179 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 180 (Or: 64597 64596 64599 64600 etc.) 182 Figure 2: BGP Outbound Route Processing 184 Above cases are also being known As-Path Poisoning Attacks. 186 This document proposes to enhance AS-Loop Detection for BGP Inbound/ 187 Outbound Route Processing. This could empower networks to quickly 188 and accurately figure out they're being victimized. 190 2. Terminology 192 The following terminology is used in this document. 194 AS: Autonomous System 196 BGP: Border Gateway Protocol 198 BGP hijacking : is the illegitimate takeover of groups of IP 199 addresses by corrupting Internet routing tables maintained using the 200 Border Gateway Protocol (BGP). (Sometimes referred to as prefix 201 hijacking, route hijacking or IP hijacking) 203 EBGP: External BGP 205 ISP: Internet Service Provider 207 3. Enhanced AS-Loop Detection for BGP Inbound Route Processing 209 This section proposes to enhance AS Loop Detection for BGP Inbound 210 Route Processing. 212 As shown in Figure 3, when receiving the routes from AS64597, AS64596 213 should check whether its AS number is already in the AS-Path, If yes, 214 it further analyzes the location of the AS64596 in the received 215 AS_Path: 217 Case 1: AS 64596 is listed as Origin AS in the AS-Path 219 Lookup the local resource database (Such as ROA Cache) and determine 220 whether the route is originated from the AS 64596. 222 o Result 1: AS 64596 has no corresponding prefix; it is identified 223 as a purely forged AS_Path prefix hijacking event, which is 224 recorded as incident type 1. 226 o Result 2: The corresponding prefix is a sub-prefix of a certain 227 prefix of the AS 64596 and the AS 64596 has not advertise it. For 228 example, the prefix being hold by the AS 64596 is 10.10.128.0/17, 229 and the receiving route prefix is 10.10.192.0/24, the latter is a 230 sub-prefix of the former, which indicates that this is a forged 231 AS_Path sub-prefix hijacking event, which is recorded as incident 232 type 2. 234 o Result 3: The corresponding prefix is a sub-prefix of a certain 235 prefix of the AS 64596 and the AS 64596 has only advertised to 236 some special ASNs, and only wants it to be used internally by 237 those ASNs. The AS 64596 recognizes that At least one special AS 238 violates the route policy. Which is recorded as incident type 3. 240 o Result 4: The corresponding prefix is originated by the AS 64596, 241 this is the normal case. 243 Case 2: AS 64596 is listed as transit AS in the AS-Path 245 For example, AS-Path looks like the following form AS64596's 246 perspective: 248 (possible other AS), left AS, local AS(64596), right AS, (possible 249 other AS) 251 At this point, AS 64596 can lookup the local resource database and 252 check whether there is a real AS relationship between the local AS 253 and the left AS and the right AS. (From the perspective of the local 254 AS, it can manage/hold the AS-relationship database between the local 255 AS and each of its neighboring ASs (such as C2P, P2P, P2C, etc.).) 257 o Result 1: At least one of the AS ( the left AS or the right AS) 258 has no actual AS relationship with the local AS (i.e. A never 259 before seen AS-AS adjacency). It is a purely forged AS_Path 260 prefix hijacking event. Which is recorded as incident type 4. 262 o Result 2: The AS relationships between the local AS and the left 263 AS and the right AS are correct, but the local AS has not 264 previously process this prefix , so it can be recognized that this 265 is a forged route. We classify this incident type as type 5. 267 o Result 3: The AS relationships between the AS and the left AS and 268 the right AS are correct, and the local AS 64596 has previously 269 processed the prefix, this is the normal case. 271 Enhanced AS-Loop-Detecting at this point 272 To identify the attack/forged information 273 | 274 | 275 v x.y.z.0/24 Origin AS 64600 276 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 277 Normal Case: 278 <-- x.y.z.0/24, AS-Path: 64597 64598 64599 64600 280 Forged Case 1: 281 <-- x.y.z.0/24, AS-Path: 64596 64595 282 (Or: 64597 64598 64596 etc.) 284 Forged Case 2: 285 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 286 (Or: 64597 64596 64599 64600 etc.) 288 Figure 3: Enhance for BGP Inbound Route Processing 290 The local AS 64596 inputs the detected result to the route hijacking 291 management module, or/and records the log or/and the alarm 292 information, and the maintenance team of the local AS 64596 can 293 notify the maintenance team of the relevant AS to correct the error 294 in their networks . 296 After the above steps are added, the stability and security of the 297 network can be improved. 299 4. Enhanced AS-Loop Detection for BGP Outbound Route Processing 301 This section proposes to enhance AS Loop Detection for BGP Outbound 302 Route Processing. 304 If Split-Horizon Enable, Enhanced AS-Loop-Detecting at this point 305 To identify the attack/forged information 306 | 307 | 308 v x.y.z.0/24 Origin AS 64600 309 AS64595---AS64596---AS64597---AS64598---AS64599----AS64600 310 Normal Case: 311 <-- x.y.z.0/24, AS-Path: 300 64598 64599 64600 313 Forged Case 1: 314 <-- x.y.z.0/24, AS-Path: 64597 64596 315 (Or: 64597 64598 64596 etc.) 317 Forged Case 2: 318 <-- x.y.z.0/24, AS-Path: 64597 64596 64600 319 (Or: 64597 64596 64599 64600 etc.) 321 Figure 4: Enhance for BGP Outbound Route Processing 323 As shown in Figure 4, when sending the routes from AS64597 to 324 AS64596, AS64597 will check whether the AS number 64596 is already in 325 the AS-Path, If yes, it can further analyzes the location of the 326 AS64596 in the received AS_Path: 328 The remaining processing steps are the same as the previous section. 330 5. Benefits 332 After the enhancements of the AS Loop Detection for BGP Inbound/ 333 Outbound Route Processing are added, the stability and security of 334 the network can be improved. 336 6. Acknowledgements 338 The authors would like to acknowledge the review and inputs from Gang 339 Yan, Zhenbin Li, Aijun Wang, Jeff Haas, Robert Razsuk, Alexander 340 Asimov and the working group. 342 . 344 7. IANA Considerations 346 TBD. 348 8. Security Considerations 350 TBD. 352 9. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 360 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 361 DOI 10.17487/RFC4271, January 2006, 362 . 364 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 365 "Multiprotocol Extensions for BGP-4", RFC 4760, 366 DOI 10.17487/RFC4760, January 2007, 367 . 369 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 370 Monitoring Protocol (BMP)", RFC 7854, 371 DOI 10.17487/RFC7854, June 2016, 372 . 374 Authors' Addresses 376 Huanan Chen 377 China Telecom 378 109, West Zhongshan Road, Tianhe District 379 Guangzhou 510000 380 China 382 Email: chenhn8.gd@chinatelecom.cn 384 Di Ma 385 ZDNS 386 4 South 4th St. Zhongguancun 387 Beijing, Haidian 388 China 390 Email: madi@zdns.cn 391 Yunan Gu 392 Huawei 393 Huawei Bld., No.156 Beiqing Rd. 394 Beijing 100095 395 China 397 Email: guyunan@huawei.com 399 Shunwan Zhuang 400 Huawei 401 Huawei Bld., No.156 Beiqing Rd. 402 Beijing 100095 403 China 405 Email: zhuangshunwan@huawei.com 407 Haibo Wang 408 Huawei 409 Huawei Bld., No.156 Beiqing Rd. 410 Beijing 100095 411 China 413 Email: rainsword.wang@huawei.com