idnits 2.17.1 draft-ietf-idr-route-leak-detection-mitigation-10.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '...this information SHOULD be used to aut...' RFC 2119 keyword, line 205: '... its ASN value, it MUST not be changed...' RFC 2119 keyword, line 216: '...n this document) MUST also implement a...' RFC 2119 keyword, line 260: '...ingress router (receiver) MUST add L =...' RFC 2119 keyword, line 285: '... been performed, a sender MUST perform...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the RLP community is present in an update, it will always contain a single DO. However, L need not be always present. (Note: The bits designated to carry L may be always present along with a DO, except that a default value (all zeros) is carried in L when no AS in the current AS path needed to assert L.) Once an AS asserts L (Leak detected) by inserting its ASN value, it MUST not be changed subsequently as the update propagates. But the ASN value in DO (Down Only) is changeable along the AS path per its definition above. -- The document date (October 22, 2018) is 2010 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC4271' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC6811' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC7454' is defined on line 405, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-03 == Outdated reference: A later version (-11) exists of draft-ietf-idr-route-leak-detection-mitigation-09 == Outdated reference: A later version (-09) exists of draft-sriram-idr-route-leak-solution-discussion-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR and SIDR K. Sriram, Ed. 3 Internet-Draft USA NIST 4 Intended status: Standards Track A. Azimov, Ed. 5 Expires: April 25, 2019 Qrator Labs 6 October 22, 2018 8 Methods for Detection and Mitigation of BGP Route Leaks 9 draft-ietf-idr-route-leak-detection-mitigation-10 11 Abstract 13 Problem definition for route leaks and enumeration of types of route 14 leaks are provided in RFC 7908. This document describes a solution 15 for detection and mitigation route leaks which is based on conveying 16 route-leak protection (RLP) information in a Border Gateway Protocol 17 (BGP) community. The RLP information is carried in a new well-known 18 transitive BGP community, called the RLP community. The RLP 19 community helps with detection and mitigation of route leaks at ASes 20 downstream from the leaking AS (in the path of the BGP update). This 21 is an inter-AS (multi-hop) solution mechanism. This solution 22 complements the intra-AS (local AS) route-leak avoidance solution 23 that is described in ietf-idr-bgp-open-policy draft. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Mechanisms for Detection and Mitigation of Route Leaks . . . 3 61 2.1. Ascertaining Peering Relationship . . . . . . . . . . . . 3 62 2.2. Route-Leak Protection (RLP) Semantics . . . . . . . . . . 4 63 2.2.1. Format of the RLP Community . . . . . . . . . . . . . 5 64 2.3. Route Leak Detection Rules and the Ingress Router 65 (Receiver) Actions . . . . . . . . . . . . . . . . . . . 6 66 2.4. Route Selection Policy . . . . . . . . . . . . . . . . . 6 67 2.5. Egress Router (Sender) Actions . . . . . . . . . . . . . 7 68 3. Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 6.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 RFC 7908 [RFC7908] provides a definition of the route leak problem, 81 and enumerates several types of route leaks. For this document, the 82 definition that is applied is that a route leak occurs when a route 83 received from a transit provider or a lateral peer is forwarded 84 (against commonly used policy) to another transit provider or a 85 lateral peer. The commonly used policy is that a route received from 86 a transit provider or a lateral peer may be forwarded "down only" to 87 customers. 89 This document describes a solution for detection and mitigation route 90 leaks which is based on conveying route-leak protection (RLP) 91 information in a Border Gateway Protocol (BGP) community. The RLP 92 information is carried in a new well-known transitive BGP community, 93 called the RLP community. The RLP community helps with detection and 94 mitigation of route leaks at ASes downstream from the leaking AS (in 95 the path of the BGP update). This is an inter-AS (multi-hop) 96 solution mechanism. This solution complements the intra-AS (local 97 AS) route-leak avoidance solution that is described in 98 [I-D.ietf-idr-bgp-open-policy]. 100 Previously, an optional transitive BGP RLP Attribute was proposed to 101 carry the RLP information 102 [I-D.ietf-idr-route-leak-detection-mitigation]. However, this 103 document proposes a well-known transitive BGP community to carry the 104 RLP information, with the intention of promoting faster adoption. 106 The inter-AS RLP mechanism described here can be incrementally 107 deployed. Early adopters would see significant benefits. If a group 108 of big ISPs deploy RLP, then they would be helping each other by 109 blocking route leaks originated within one's customer cone from 110 propagating into a peer's AS or their customer cone. 112 2. Mechanisms for Detection and Mitigation of Route Leaks 114 There are two considerations for route leaks: (1) Prevention of route 115 leaks from a local AS [I-D.ietf-idr-bgp-open-policy], and (2) 116 Detection and mitigation of route leaks in ASes that are downstream 117 from the leaking AS (in the path of BGP update). This document 118 specifies the latter. 120 2.1. Ascertaining Peering Relationship 122 There are four possible peering relationships (i.e., roles) an AS can 123 have with a neighbor AS: (1) Provider: transit-provider for all 124 prefixes exchanged, (2) Customer: customer for all prefixes 125 exchanged, (3) Lateral Peer: lateral peer (i.e., non-transit) for all 126 prefixes exchanged, and (4) Complex: different relationships for 127 different sets of prefixes [Luckie]. For the complex case, the 128 peering role types provider, customer, or lateral peer apply for 129 different non-overlapping sets of prefixes. 131 Operators rely on some form of out-of-band (OOB) (i.e., external to 132 BGP) communication to exchange information about their peering 133 relationship, AS number, interface IP address, etc. If the 134 relationship is complex, the OOB communication also includes the sets 135 of prefixes for which they have different roles. 136 [I-D.ietf-idr-bgp-open-policy] introduces a method of re-confirming 137 the BGP Role during BGP OPEN messaging (except when the role is 138 complex). It defines a new BGP Role capability, which helps in re- 139 confirming the relationship when it is provider, customer, or lateral 140 peer. BGP Role does not replace the OOB communication since it 141 relies on the OOB communication to set the role type in the BGP OPEN 142 message. However, BGP Role provides a means to double check, and if 143 there is a contradiction detected via the BGP Role messages, then a 144 Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy]. 146 When the BGP relationship information has been correctly exchanged 147 including the sets of prefixes with different roles (if complex), 148 then this information SHOULD be used to automatically set the role 149 per-prefix with each peer. For example, if the local AS's role is 150 Provider with a neighbor AS, then the per-prefix role is set to 151 'Provider' for all prefixes sent to the neighbor, and set to 152 'Customer' for all prefixes received from the neighbor. 154 Once the per-prefix roles are set, this information is used in the 155 RLP solution mechanism that is described in this document. 157 2.2. Route-Leak Protection (RLP) Semantics 159 The key principle is that, in the event of a route leak, a receiving 160 router in a transit-provider AS (e.g., referring to Figure 1, ISP2 161 (AS2) router) should be able to detect from the RLP community in the 162 update message that its customer AS (e.g., AS3 in Figure 1) should 163 not have forwarded the update (towards the transit-provider AS). 164 Likewise when the update is received from a lateral peer. This means 165 that at least one of the ASes in the AS path of the update put RLP 166 information in RLP community to indicate that it sent the update to 167 its customer or lateral peer, but forbade any subsequent 'Up' 168 (customer to provider) or 'Lateral' (peer to peer) forwarding. 170 /\ /\ 171 \ route-leak(P)/ 172 \ propagated / 173 \ / 174 +------------+ peer +------------+ 175 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> 176 / ------------+ prefix(P) +------------+ route-leak(P) 177 | prefix | \ update /\ \ propagated 178 \ (P) / \ / \ 179 ------- prefix(P) \ / \ 180 update \ / \ 181 \ /route-leak(P) \/ 182 \/ / 183 +---------------+ 184 | customer(AS3) | 185 +---------------+ 187 Figure 1: Illustration of the basic notion of a route leak. 189 The RLP information contained in the RLP community consists of one or 190 two AS numbers (ASNs) and has the following semantics: 192 1. Down Only (DO) indication: ASN of the most recent RLP-aware AS in 193 the path to assert that it sent the update to a customer or 194 lateral peer; 196 2. Leak detected (L) indication: ASN of the first RLP-aware AS in 197 the path to assert that it forwarded the route from a customer or 198 lateral peer despite detecting a leak (to avoid unreachability). 200 If the RLP community is present in an update, it will always contain 201 a single DO. However, L need not be always present. (Note: The bits 202 designated to carry L may be always present along with a DO, except 203 that a default value (all zeros) is carried in L when no AS in the 204 current AS path needed to assert L.) Once an AS asserts L (Leak 205 detected) by inserting its ASN value, it MUST not be changed 206 subsequently as the update propagates. But the ASN value in DO (Down 207 Only) is changeable along the AS path per its definition above. 209 Design assumption 1: Operators desire to avoid unreachability. So, a 210 design assumption here is that in the absence of an alternative 211 route, an AS may select and forward a route that is detected to be a 212 leak. (Note: This is the reason Leak detected (L) indication is part 213 of the design.) 215 Design assumption 2: An AS that is RLP-aware (i.e., implements the 216 RLP solution in this document) MUST also implement an intra-AS 217 solution for route leak avoidance in the local AS. The latter 218 solution uses an intra-AS signaling mechanism (see 219 [I-D.ietf-idr-bgp-open-policy], Section 3.7 of [RLP-Discussion]). By 220 doing this, the AS locally prevents the leaking of routes learned 221 from a transit provider or lateral peer to another transit provider 222 or lateral peer. Why this is critical to the overall solution is 223 made clear in slides 7 and 8 of [sriram2]. 225 2.2.1. Format of the RLP Community 227 The format of the RLP community using a single Large Community is 228 shown in Figure 2. 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Global Administrator (IANA assigned for RLP) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Local Data Part 1 = DO (ASN value) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Local Data Part 2 = L (ASN value) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 2: Format of the RLP Community using a Large Community 241 [RFC8092]. 243 2.3. Route Leak Detection Rules and the Ingress Router (Receiver) 244 Actions 246 A received BGP update is determined to be a route leak if: 248 1. if L is present in the update; 250 2. else (L is absent), the update is received from a customer and DO 251 is present; 253 3. else (L is absent), the update is received from a lateral peer 254 and DO is present that is not the lateral peer's ASN. 256 Note: Here by "L is present" we mean that its value is not the 257 default value (all zeros) but is a proper ASN. Effectively "L is 258 absent" if its value is the default value. 260 In steps 2 and 3 above, the ingress router (receiver) MUST add L = 261 local ANS. Doing this prior to the best path selection process is 262 necessary. Also, if the route is selected as best path, then L is 263 already set correctly before the egress router (sender) acts on it. 265 2.4. Route Selection Policy 267 Minimum Default Policy: Whenever there is a choice between a customer 268 route and a provider route that are both detected to be leaks (L is 269 present), then lower the LocalPref to X (TBD by operator) for each of 270 them. Then shortest path criterion would typically make the customer 271 route preferred. (Note: This would help mitigate any possibility of 272 persistent oscillation; see slide #7 in [sriram1].) 274 Generalized Minimum Default Policy: Whenever there is a choice 275 between multiple routes (customer/peer/provider) and each is detected 276 to be a leak (L is present), then lower the LocalPref to X TBD by 277 operator) for each of them. Then apply shortest path criterion. 278 (Note: Some network operators may find this inadequate; see scenarios 279 #3 and #6 in slides #14 and #16, respectively, in [sriram2]. But 280 they may locally modify their policy while respecting the basic 281 principle.) 283 2.5. Egress Router (Sender) Actions 285 After best path selection has been performed, a sender MUST perform 286 the following RLP-related actions on the update to be propagated: 288 1. When propagating a route originated by the local AS to a customer 289 or lateral peer, add DO = local ASN; 291 2. Else, when propagating a route that already includes a DO (i.e., 292 was received with a DO) to a customer or lateral peer, replace 293 the DO value with the local ASN. 295 3. Pseudo Code 297 [Begin: receiver action for route leak detection] 299 {Comment: This precedes route selection policy.} 301 if received route includes L, then save the route in RIB-in as is; 303 else (L is absent), if route is received from a customer and DO is 304 preset, then add L = local ASN; 306 else (L is absent), if route is received from a lateral peer and 307 DO is present that is not the lateral peer's ASN, then add L = 308 local ASN 310 {Comment: "Route does not include L" or "L is absent" only if L is 311 either literally absent or has the default (all zeros) value.} 313 [End: receiver action for route leak detection] 315 ---------------------------------------------------------- 317 [Begin: route selection policy] 319 for each route that includes L, lower the LocalPref to X (TBD); 320 apply best path selection policy* 322 {*Comment: E.g., best path selection based on LocalPref first and 323 then shortest path.} 325 [End: route selection policy] 327 ---------------------------------------------------------- 329 [Begin: sender action] 331 {Comment: RLP (includes DO and L or just DO) is a *transitive* BGP 332 community and should propagate globally.} 334 when propagating a route originated by local AS to a customer or 335 lateral peer, add DO = local ASN; 337 when propagating a route that includes a DO (i.e., was received 338 with a DO) to a customer or lateral peer, replace the DO value 339 with the local ASN; 341 [End: sender action] 343 4. Security Considerations 345 With the use of BGP community, there is often a concern that the 346 community propagates beyond its intended perimeter and causes harm 347 [streibelt]. However, that concern does not apply to the RLP 348 community because it is a transitive community that must propagate as 349 far as the update goes. 351 The proposed Route-Leak Protection (RLP) information carried in the 352 RLP community can benefit from cryptographic protection to prevent 353 abuse by malicious actors in the AS path. In the future, if there is 354 BGPsec deployment, the RLP information can be encoded in the Flags 355 field in the Secure_Path Segment in BGPsec updates [RFC8205]. So, 356 the cryptographic security mechanisms in BGPsec can also secure the 357 RLP information. The reader is directed to the security 358 considerations provided in [RFC8205]. 360 5. IANA Considerations 362 IANA is requested to register RLP in the well-known Large Community 363 [RFC8092] registry (need help to clarify this). IANA is requested to 364 allocate a new Global Administrator ID for the RLP community (Large 365 Community) (see Figure 2 in this document). Note that BGP Path 366 Attribute value for Large Community is 32 (IANA allocated) [RFC8092]. 368 6. References 369 6.1. Normative References 371 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 372 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 373 DOI 10.17487/RFC4271, January 2006, 374 . 376 6.2. Informative References 378 [draft-dickson-sidr-route-leak-solns] 379 Dickson, B., "Route Leaks -- Proposed Solutions", IETF 380 Internet Draft (expired), March 2012, 381 . 384 [I-D.ietf-idr-bgp-open-policy] 385 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 386 Sriram, "Route Leak Prevention using Roles in Update and 387 Open messages", draft-ietf-idr-bgp-open-policy-03 (work in 388 progress), June 2018. 390 [I-D.ietf-idr-route-leak-detection-mitigation] 391 Sriram, K. and A. Azimov, "Methods for Detection and 392 Mitigation of BGP Route Leaks", draft-ietf-idr-route-leak- 393 detection-mitigation-09 (work in progress), July 2018. 395 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 396 kc. claffy, "AS Relationships, Customer Cones, and 397 Validation", IMC 2013, October 2013, 398 . 400 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 401 Austein, "BGP Prefix Origin Validation", RFC 6811, 402 DOI 10.17487/RFC6811, January 2013, 403 . 405 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 406 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 407 February 2015, . 409 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 410 and B. Dickson, "Problem Definition and Classification of 411 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 412 2016, . 414 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 415 I., and N. Hilliard, "BGP Large Communities Attribute", 416 RFC 8092, DOI 10.17487/RFC8092, February 2017, 417 . 419 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 420 Specification", RFC 8205, DOI 10.17487/RFC8205, September 421 2017, . 423 [RLP-Discussion] 424 Sriram (Ed.), K., "Design Discussion of Route Leaks 425 Solution Methods", Work in Progress, draft-sriram-idr- 426 route-leak-solution-discussion-00, July 2018, 427 . 430 [sriram1] Sriram et al., K., "Route Leaks Solution Merger of RLP and 431 eOTC Drafts", Presented at the IDR Working Group Meeting, 432 IETF-102, Montreal, July 2018, 433 . 436 [sriram2] Sriram et al., K., "Solution for Route Leaks Using BGP 437 Communities", Authors Team Discussion Slides, October 438 2018, . 441 [streibelt] 442 Streibelt et al., F., "BGP Communities: Even more Worms in 443 the Routing Can", ACM IMC, October 2018, 444 . 446 Acknowledgements 448 The authors wish to thank John Scudder and Susan Hares for their 449 review and comments. 451 Contributors 453 The following people made significant contributions to this document 454 and should be considered co-authors: 456 Brian Dickson 457 Independent 458 Email: brian.peter.dickson@gmail.com 460 Doug Montgomery 461 USA National Institute of Standards and Technology 462 Email: dougm@nist.gov 464 Keyur Patel 465 Arrcus 466 Email: keyur@arrcus.com 468 Andrei Robachevsky 469 Internet Society 470 Email: robachevsky@isoc.org 472 Eugene Bogomazov 473 Qrator Labs 474 Email: eb@qrator.net 476 Randy Bush 477 Internet Initiative Japan 478 Email: randy@psg.com 480 Authors' Addresses 482 Kotikalapudi Sriram (editor) 483 USA National Institute of Standards and Technology 484 100 Bureau Drive 485 Gaithersburg, MD 20899 486 United States of America 488 Email: ksriram@nist.gov 490 Alexander Azimov (editor) 491 Qrator Labs 492 1-Y Magistral'nyy Tupik 493 Moskva, XYZ 123007 494 Russia 496 Email: aa@qrator.net