idnits 2.17.1 draft-ietf-idr-route-leak-detection-mitigation-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-sidr-bgpsec-protocol], [RFC6811], [I-D.ietf-grow-route-leak-problem-definition]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 253: '...AS3 in Figure 1) SHOULD NOT have forwa...' RFC 2119 keyword, line 282: '... RLP field value SHOULD be set to one ...' RFC 2119 keyword, line 288: '...g that the route SHOULD NOT be forward...' RFC 2119 keyword, line 292: '... RLP indications SHOULD be set on a pe...' RFC 2119 keyword, line 296: '...arios when a sending AS SHOULD set the...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3104 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) == Missing Reference: 'RFC 6811' is mentioned on line 22, but not defined == Unused Reference: 'Cowie2010' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'Cowie2013' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'Gill' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'Hiran' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'Huston2012' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'Huston2014' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'Kapela-Pilosov' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'Khare' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'Labovitz' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'LRL' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'Luckie' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'Madory' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'Mauch' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'Mauch-nanog' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'Paseka' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'Toonk' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'Toonk2015-A' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'Toonk2015-B' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'Zmijewski' is defined on line 783, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-grow-route-leak-problem-definition-03 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-13 -- Obsolete informational reference (is this intentional?): RFC 1105 (Obsoleted by RFC 1163) Summary: 2 errors (**), 0 flaws (~~), 23 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR and SIDR K. Sriram 3 Internet-Draft D. Montgomery 4 Intended status: Standards Track US NIST 5 Expires: April 21, 2016 B. Dickson 7 K. Patel 8 Cisco 9 A. Robachevsky 10 Internet Society 11 October 19, 2015 13 Methods for Detection and Mitigation of BGP Route Leaks 14 draft-ietf-idr-route-leak-detection-mitigation-01 16 Abstract 18 In [I-D.ietf-grow-route-leak-problem-definition], the authors have 19 provided a definition of the route leak problem, and also enumerated 20 several types of route leaks. In this document, we first examine 21 which of those route-leak types are detected and mitigated by the 22 existing origin validation (OV) [RFC 6811] and BGPSEC path validation 23 [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC 24 protocols don't offer a solution, this document suggests an 25 enhancement that would extend the route-leak detection and mitigation 26 capability of BGPSEC. The solution can be implemented in BGP without 27 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC 28 is one way of implementing it in a secure way. We do not claim to 29 have provided a solution for all possible types of route leaks, but 30 the solution covers several, especially considering some significant 31 route-leak attacks or occurrences that have been observed in recent 32 years. The document also includes a stopgap method for detection and 33 mitigation of route leaks for the phase when BGPSEC (path validation) 34 is not yet deployed but only origin validation is deployed. 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 http://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 April 21, 2016. 53 Copyright Notice 55 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 3 72 3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4 73 3.1. Route Leak Protection (RLP) Field Encoding by Sending 74 Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Recommended Actions at a Receiving Router for Detection 76 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8 77 3.3. Possible Actions at a Receiving Router for Mitigation . . 9 78 4. Stopgap Solution when Only Origin Validation is Deployed . . 9 79 5. Design Rationale and Discussion . . . . . . . . . . . . . . . 10 80 5.1. Is route-leak solution without BGPSEC a serious attack 81 vector? . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.2. Are there cases when valley-free violations can be 83 considered legitimate? . . . . . . . . . . . . . . . . . 12 84 5.3. Comparison with other methods, routing security BCP . . . 12 85 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 91 10.2. Informative References . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 In [I-D.ietf-grow-route-leak-problem-definition], the authors have 97 provided a definition of the route leak problem, and also enumerated 98 several types of route leaks. In this document, we first examine 99 which of those route-leak types are detected and mitigated by the 100 existing Origin Validation (OV) [RFC6811] and BGPSEC path validation 101 [I-D.ietf-sidr-bgpsec-protocol]. For the rest of this document, we 102 use the term BGPSEC as synonymous with path validation. The BGPSEC 103 protocol provides cryptographic protection for some aspects of BGP 104 update messages. OV and BGPSEC together offer mechanisms to protect 105 against re-originations and hijacks of IP prefixes as well as man-in- 106 the-middle (MITM) AS path modifications. Route leaks (see 107 [I-D.ietf-grow-route-leak-problem-definition] and references cited at 108 the back) are another type of vulnerability in the global BGP routing 109 system against which OV and BGPSEC so far offer only partial 110 protection. 112 For the types of route leaks enumerated in 113 [I-D.ietf-grow-route-leak-problem-definition], where the current OV 114 and BGPSEC protocols don't offer a solution, this document suggests 115 an enhancement that would extend the detection and mitigation 116 capability of BGPSEC. The solution can be implemented in BGP without 117 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC 118 is one way of implementing it in a secure way. We do not claim to 119 provide a solution for all possible types of route leaks, but the 120 solution covers several relevant types, especially considering some 121 significant route-leak occurrences that have been observed frequently 122 in recent years. The document also includes (in Section 4) a stopgap 123 method for detection and mitigation of route leaks for the phase when 124 BGPSEC (path validation) is not yet deployed but only origin 125 validation is deployed. 127 2. Related Prior Work 129 The basic idea and mechanism embodied in the proposed solution is 130 based on setting an attribute in BGP route announcement to manage the 131 transmission/receipt of the announcement based on the type of 132 neighbor (e.g. customer, transit provider, etc.). Documented prior 133 work related to said basic idea and mechanism dates back to at least 134 the 1980's. Some examples of prior work are: (1) Information flow 135 rules described in [proceedings-sixth-ietf] (see pp. 195-196); (2) 136 Link Type described in [RFC1105-obsolete] (see pp. 4-5); (3) 137 Hierarchical Recording described in 138 [draft-kunzinger-idrp-ISO10747-01] (see Section 6.3.1.12). The 139 problem of route leaks and possible solution mechanisms based on 140 encoding peering-link type information, e.g. P2C (i.e. Transit- 141 Provider to Customer), C2P (i.e. Customer to Transit-Provider), p2p 142 (i.e. peer to peer) etc., in BGPSEC updates and protecting the same 143 under BGPSEC path signatures have been discussed in IETF SIDR WG at 144 least since 2011. Dickson developed the initial Internet draft of 145 these mechanisms in a BGPSEC context; see 146 [draft-dickson-sidr-route-leak-solns]. The draft expired in 2012. 147 [draft-dickson-sidr-route-leak-solns] defined neighbor relationships 148 on a per link basis, but in the current draft the relationship in 149 encoded per prefix, as routes for prefixes with different business 150 models are often sent over the same link. Also 151 [draft-dickson-sidr-route-leak-solns] proposed a second signature 152 block for the link type encoding, separate from the path signature 153 block in BGPSEC. By contrast, in the current draft when BGPSEC-based 154 solution is considered, cryptographic protection is provided for 155 Route Leak Protection (RLP) encoding using the same signature block 156 as that for path signatures (see Section 3.1). 158 3. Mechanisms for Detection and Mitigation of Route Leaks 160 Referring to the enumeration of route leaks discussed in 161 [I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the 162 route-leak detection capability offered by OV and BGPSEC for 163 different types of route leaks. (Note: Prefix filtering is not 164 considered here in this table. Please see Section 4.) 166 A detailed explanation of the contents of Table 1 is as follows. It 167 is readily observed that route leaks of Types 1, 2, 3, and 4 are not 168 detected by OV or even by BGPSEC. Type 5 route leak involves 169 changing a prefix to a more specific; such a modified update will 170 fail BGPSEC checks. Clearly, Type 6 route leak involves re- 171 origination or hijacking, and hence can be detected by OV. In the 172 case of Type 6 route leak, there would be no existing ROAs to 173 validate a re-originated prefix or more specific, but instead a 174 covering ROA would normally exist with the legitimate AS, and hence 175 the update will be considered Invalid by OV. 177 +---------------------------------+---------------------------------+ 178 | Type of Route Leak | Detection Coverage and Comments | 179 +---------------------------------+---------------------------------+ 180 | Type 1: U-Shaped Turn with Full | Neither OV nor BGPSEC (in its | 181 | Prefix | current form) detects Type 1. | 182 | ------------------------------- | ------------------------------- | 183 | Type 2: Lateral ISP-ISP-ISP | Neither OV nor BGPSEC (in its | 184 | Leak | current form) detects Type 2. | 185 | ------------------------------- | ------------------------------- | 186 | Type 3: Leak of Transit- | Neither OV nor BGPSEC (in its | 187 | Provider Prefixes to Peer | current form) detects Type 3. | 188 | ------------------------------- | ------------------------------- | 189 | Type 4: Leak of Peer Prefixes | Neither OV nor BGPSEC (in its | 190 | to Transit Provider | current form) detects Type 4. | 191 | ------------------------------- | ------------------------------- | 192 | Type 5: U-Shaped Turn with More | In OV, the ROA maxLength may | 193 | Specific Prefix | offer detection of Type 5 in | 194 | | some cases; BGPSEC (in its | 195 | | current form) always detects | 196 | | Type 5. | 197 | ------------------------------- | ------------------------------- | 198 | Type 6: Prefix Re-Origination | OV by itself detects Type 6; | 199 | with Data Path to Legitimate | BGPSEC does not detect Type 6. | 200 | Origin | | 201 | ------------------------------- | ------------------------------- | 202 | Type 7: Accidental Leak of | For internal prefixes never | 203 | Internal Prefixes and More | meant to be seen (i.e. routed) | 204 | Specifics | on the Internet, OV helps | 205 | | detect their leak; they might | 206 | | either have no covering ROA or | 207 | | have an AS0-ROA to always | 208 | | filter them. In the case of | 209 | | accidental leak of more | 210 | | specifics, OV may offer some | 211 | | detection due to ROA maxLength. | 212 | | BGPSEC does not catch Type 7. | 213 +---------------------------------+---------------------------------+ 215 Table 1: Examination of Route-Leak Detection Capability of Origin 216 Validation and Current BGPSEC Path Validation 218 In the case of Type 7 leaks involving internal prefixes that are not 219 meant to be routed in the Internet, they are likely to be detected by 220 OV. That is because such prefixes might either have no covering ROA 221 or have an AS0-ROA to always filter them. In the case of Type 7 222 leaks that are due to accidental leak of more specifics, they may be 223 detected due to violation of ROA maxLength. BGPSEC does not catch 224 Type 7. However, route leaks of Type 7 are least problematic due to 225 the following reasons. In the case of leak of more specifics, the 226 offending AS is itself the legitimate destination of the leaked more- 227 specific prefixes. Hence, in most cases of this type, the data 228 traffic is neither misrouted not denied service. Also, leaked 229 announcements of Type 7 are short-lived and typically withdrawn 230 quickly following the announcements. Further, the MaxPrefix limit 231 may kick-in in some receiving routers and that helps limit the 232 propagation of sometimes large number of leaked routes of Type 7. 234 Realistically, BGPSEC may take a much longer time being deployed than 235 OV. Hence solution proposals for route leaks should consider both 236 scenarios: (A) OV only (without BGPSEC) and (B) OV plus BGPSEC. 237 Assuming an initial scenario A, and based on the above discussion and 238 Table 1, it is evident that in our proposed solution method, we need 239 to focus primarily on route leaks of Types 1, 2, 3, 4, and 5. In 240 Section 3.1 and Section 3.2, we describe a simple addition to BGP 241 that facilitates detection of route leaks of Types 1, 2, 3, 4, and 5. 242 The simple addition involves a Route Leak Protection (RLP) field, 243 which is carried in an optional transitive path attribute in BGP. 244 When BGPSEC is deployed, the RLP field will be accommodated in the 245 existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is 246 cryptographically protected under path signatures. 248 3.1. Route Leak Protection (RLP) Field Encoding by Sending Router 250 The key principle is that, in the event of a route leak, a receiving 251 router in a transit-provider AS (e.g. referring to Figure 1, ISP2 252 (AS2) router) should be able to detect from the update message that 253 its customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the 254 update (towards the transit-provider AS). This means that at least 255 one of the ASes in the AS path of the update has indicated that it 256 sent the update to its customer or lateral (i.e. non-transit) peer, 257 but forbade any subsequent 'Up' forwarding (i.e. from a customer AS 258 to its transit-provider AS). For this purpose, a Route Leak 259 Protection (RLP) field to be set by a sending router is proposed to 260 be used for each AS hop. 262 /\ /\ 263 \ route-leak(P)/ 264 \ propagated / 265 \ / 266 +------------+ peer +------------+ 267 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> 268 / ------------+ prefix(P) +------------+ route-leak(P) 269 | prefix | \ update /\ \ propagated 270 \ (P) / \ / \ 271 ------- prefix(P) \ / \ 272 update \ / \ 273 \ /route-leak(P) \/ 274 \/ / 275 +---------------+ 276 | customer(AS3) | 277 +---------------+ 279 Figure 1: Illustration of the basic notion of a route leak. 281 For the purpose of route leak detection and mitigation proposed in 282 this document, the RLP field value SHOULD be set to one of two values 283 as follows: 285 o 00: This is the default value (i.e. "nothing specified"), 287 o 01: This is the 'Do not Propagate Up or Lateral' indication; 288 sender indicating that the route SHOULD NOT be forwarded 'Up' 289 towards a transit-provider AS or to a lateral (i.e. non-transit) 290 peer AS. 292 The RLP indications SHOULD be set on a per prefix and per neighbor AS 293 basis. This is because updates for prefixes with different business 294 models are often sent over the same link between ASes. 296 There are two different scenarios when a sending AS SHOULD set the 297 '01' indication in an update: (1) when sending the update to a 298 customer AS, and (2) when sending the update to a lateral peer (i.e. 299 non-transit) AS. In essence, in both scenarios, the intent of '01' 300 indication is that the neighbor AS and any receiving AS along the 301 subsequent AS path SHOULD NOT forward the update 'Up' towards its 302 (receiving AS's) transit-provider AS or laterally towards its peer 303 (i.e. non-transit) AS. When sending an update 'Up' to a transit- 304 provider AS, the RLP encoding should be set to the default value of 305 '00'. When a sending AS sets the RLP encoding to '00', it is 306 indicating to the receiving AS that the update can be propagated in 307 any direction (i.e. towards transit-provider, customer, or lateral 308 peer). This two-state specification in the RLP field can be shown to 309 work for detection and mitigation of route leaks of Types 1, 2, 3, 4, 310 and 5, which are the focus here (see Section 3.2 and Section 3.3). 311 The '10' and '11' values in the RLP field (assuming that two bits are 312 used to encode it) are currently unassigned, and reserved for 313 possible future use. 315 The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] 316 updates in an optional transitive path attribute. In BGPSEC enabled 317 routers, the RLP encoding SHOULD be accommodated in the existing 318 Flags field in BGPSEC updates. The Flags field is part of the 319 Secure_Path Segment in BPGSEC updates 320 [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags 321 field is available for each AS hop, and currently only the first bit 322 is used in BGPSEC. So there are 7 bits that are currently unused in 323 the Flags field. Two (or more if needed) of these bits can be 324 designated for the RLP field. Since the BGPSEC protocol 325 specification requires a sending AS to include the Flags field in the 326 data that are signed over, the RLP field for each hop (assuming it 327 would be part of the Flags field) will be protected under the sending 328 AS's signature. 330 3.2. Recommended Actions at a Receiving Router for Detection of Route 331 Leaks 333 We provide here an example set of receiver actions that work to 334 detect and mitigate route leaks of Types 1, 2, 3, 4, and 5. This 335 example algorithm serves as a proof of concept. However, other 336 receiver algorithms or procedures can be designed (based on the same 337 sender specification as in Section 3.1) and may perform with greater 338 efficacy, and are by no means excluded. 340 A recommended receiver algorithm for detecting a route leak is as 341 follows: 343 A receiving router SHOULD mark an update as a Route-Leak if ALL of 344 the following conditions hold true: 346 1. The update is received from a customer or lateral peer AS. 348 2. It is Valid in accordance with the Origin Validation (OV) and 349 BGPSEC protocols. (Note: BGPSEC validation is not applicable if 350 update is not signed.) 352 3. The update has the RLP field set to '01' (i.e. 'Do not Propagate 353 Up or Lateral') indication for one or more hops (excluding the 354 most recent) in the AS path. 356 The reason for stating "excluding the most recent" in the above 357 algorithm is as follows. An ISP should look at RLP values set by 358 ASes preceding the immediate sending AS in order to ascertain a leak. 359 The receiving router already knows that the most recent hop in the 360 update is from its customer or lateral-peer AS to itself, and it does 361 not need to rely on the RLP field value set by said AS for detection 362 of route leaks. 364 A receiving router expects the RLP field value for any hop in the AS 365 path to be either 00 or 01. However, if a different value (say, 10 366 or 11) is found in the RLP field, then an error condition will get 367 flagged, and any further action is TBD. 369 3.3. Possible Actions at a Receiving Router for Mitigation 371 After applying the above detection algorithm, a receiving router may 372 use any policy-based algorithm of its own choosing to mitigate any 373 detected route leaks. An example receiver algorithm for mitigating a 374 route leak is as follows: 376 o If an update from a customer or lateral peer AS is marked as a 377 'Route-Leak', then the receiving router SHOULD prefer an alternate 378 unmarked route if available. 380 o If no alternate unmarked route is available, then the route marked 381 as a 'Route-Leak' MAY be accepted. 383 A basic principle here is that the presence of '01' value in the RLP 384 field corresponding to one or more AS hops in the AS path of an 385 update coming from a customer AS informs a receiving router in a 386 transit-provider AS that a route leak is likely occurring. The 387 transit-provider AS then overrides the "prefer customer route" 388 policy, and instead prefers an alternate 'clean' route learned from 389 another customer, a lateral peer, or a transit provider over the 390 'marked' route from the customer in question. 392 4. Stopgap Solution when Only Origin Validation is Deployed 394 During a phase when BGPSEC path validation has not yet been deployed 395 but only origin validation has been deployed, it would be good have a 396 stopgap solution for route leaks. The stopgap solution can be in the 397 form of construction of a prefix filter list from ROAs. A suggested 398 procedure for constructing such a list comprises of the following 399 steps: 401 o ISP makes a list of all the ASes (Cust_AS_List) that are in its 402 customer cone (ISP's own AS is also included in the list). (Some 403 of the ASes in Cust_AS_List may be multi-homed to another ISP and 404 that is OK.) 406 o ISP downloads from the RPKI repositories a complete list 407 (Cust_ROA_List) of valid ROAs that contain any of the ASes in 408 Cust_AS_List. 410 o ISP creates a list of all the prefixes (Cust_Prfx_List) that are 411 contained in any of the ROAs in Cust_ROA_List. 413 o Cust_Prfx_List is the allowed list of prefixes that is permitted 414 by the ISP's AS, and will be forwarded by the ISP to upstream 415 ISPs, customers, and peers. 417 o A route for a prefix that is not in Cust_Prfx_List but announced 418 by one of ISP's customers is 'marked' as a potential route leak. 419 Further, the ISP's router SHOULD prefer an alternate route that is 420 Valid (i.e. valid according to origin validation) and 'clean' 421 (i.e. not marked) over the 'marked' route. The alternate route 422 may be from a peer, transit provider, or different customer. 424 Special considerations with regard to the above procedure may be 425 needed for DDoS mitigation service providers. They typically 426 originate or announce a DDoS victim's prefix to their own ISP on a 427 short notice during a DDoS emergency. Some provisions would need to 428 be made for such cases, and they can be determined with the help of 429 inputs from DDoS mitigation service providers. 431 For developing a list of all the ASes (Cust_AS_List) that are in the 432 customer cone of an ISP, the AS path based Outbound Route Filter 433 (ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see 434 discussion in Section 5.3). 436 5. Design Rationale and Discussion 438 In this section, we will try to provide design justifications for the 439 methodology specified in Section 3, and also answer some questions 440 that are anticipated or have been raised in IETF IDR/SIDR meetings. 442 5.1. Is route-leak solution without BGPSEC a serious attack vector? 444 It has been asked if a route-leak solution without BGPSEC, i.e. when 445 RLP bits are not protected, can turn into a serious new attack 446 vector. That answer seems to be: not really! Even the NLRI and 447 AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPSEC seek to 448 fix that. Consider the following. Say, if 99% of route leaks are 449 accidental and 1% are malicious, and if route-leak solution without 450 BGPSEC eliminates the 99%, then perhaps it is worth it (step in the 451 right direction). When BGPSEC comes into deployment, the route leak 452 protection (RLP) bits can be mapped into BGPSEC (using the Flags 453 field) and then necessary security will be in place as well (within 454 each BGPSEC island as and when they emerge). 456 Further, let us consider the worst-case damage that can be caused by 457 maliciously manipulating the RLP bits in an implementation without 458 BGPSEC. Manipulation of the RLP bits can result in one of two types 459 of attacks: (a) Upgrade attack and (b) Downgrade attack. 460 Descriptions and discussions about these attack follow. In what 461 follows, P2C stands for transit provider to customer (Down); C2P 462 stands for customer to transit provider (Up), and p2p stands for peer 463 to peer (lateral or non-transit relationship). 465 (a) Upgrade attack: An AS that wants to intentionally leak a route 466 would alter the RLP encodings for the preceding hops from '01' (i.e. 467 'Do not Propagate Up or Lateral') to '00' (default) wherever 468 applicable. This poses no problem for a route that keeps propagating 469 in the 'Down' (P2C) direction. However, for a route that propagates 470 'Up' (C2P) or 'Lateral' (p2p), the worst that can happen is that a 471 route leak goes undetected. That is, a receiving router would not be 472 able to detect the leak for the route in question by the RLP 473 mechanism described here. However, the receiving router may still 474 detect and mitigate it in some cases by applying other means such as 475 prefix filters [RFC7454]. If some malicious leaks go undetected 476 (when RLP is deployed without BGPSEC) that is possibly a small price 477 to pay for the ability to detect the bulk of route leaks that are 478 accidental. 480 (b) Downgrade attack: RLP encoding is set to '01' (i.e. 'Do not 481 Propagate Up or Lateral') when it should be set to '00' (default). 482 This would result in a route being mis-detected and marked as a route 483 leak. By default RLP encoding is set to '00', and that helps reduce 484 errors of this kind (i.e. accidental downgrade incidents). Every AS 485 or ISP wants reachability for prefixes it originates and for its 486 customer prefixes. So an AS or ISP is not likely to change an RLP 487 value '00' to '01' intentionally. If a route leak is detected (due 488 to intentional or accidental downgrade) by a receiving router, it 489 would prefer an alternate 'clean' route from a transit provider or 490 peer over a 'marked' route from a customer. It may end up with a 491 suboptimal path. In order to have reachability, the receiving router 492 would accept a 'marked' route if there is no alternative that is 493 'clean'. So RLP downgrade attacks (intentional or accidental) would 494 be quite rare, and the consequences do not appear to be grave. 496 5.2. Are there cases when valley-free violations can be considered 497 legitimate? 499 There are studies in the literature [Anwar] [Giotsas] [Wijchers] 500 observing and analyzing the behavior of routes announced in BGP 501 updates using data gathered from the Internet. In particular, the 502 studies have focused on how often there appear to be valley-free 503 (e.g. Gao-Rexford [Gao] model) violations, and if they can be 504 explained [Anwar]. One important consideration for explanation of 505 violations is per-prefix routing policies, i.e. routes for prefixes 506 with different business models are often sent over the same link. 507 One encouraging result reported in [Anwar] is that when per-prefix 508 routing policies are taken into consideration in the data analysis, 509 more than 80% of the observed routing decisions fit the valley-free 510 model (see Section 4.3 and SPA-1 data in Figure 2). The authors in 511 [Anwar] also observe, "it is well known that this model [the basic 512 Gao-Rexford model and some variations of it] fails to capture many 513 aspects of the interdomain routing system. These aspects include AS 514 relationships that vary based on the geographic region or destination 515 prefix, and traffic engineering via hot-potato routing or load 516 balancing." So there may be potential for explaining the remaining 517 (20% or less) violations of valley-free as well. 519 One major design factor in the methodology described in this document 520 is that the Route Leak Protection (RLP) encoding is per prefix. So 521 the proposed solution is consistent with ISPs' per-prefix routing 522 policies. Large global and other major ISPs will be the likely early 523 adopters, and they are expected to have expertise in configuring 524 policies (including per prefix policies, if applicable), and make 525 proper use of the RLP indications on a per prefix basis. When said 526 large ISPs participate in this solution deployment, it is envisioned 527 that they would form a ring of protection against route leaks, and 528 co-operatively avoid many of the common types of route leaks that are 529 observed. Route leaks may still happen occasionally within the 530 customer cones (if some customer ASes are not participating or not 531 diligently implementing RLP), but said leaks would be much less 532 likely to propagate from one large participating ISP to another. 534 5.3. Comparison with other methods, routing security BCP 536 It is reasonable to ask if techniques considered in BCPs such 537 as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be 538 adequate to address route leaks. The prefix filtering 539 recommendations in the BCPs may be complementary but not adequate. 540 The difficulty is in ISPs' ability to construct prefix filters that 541 represent their customer cones (CC) accurately, especially when there 542 are many levels in the hierarchy within the CC. In the RLP-encoding 543 based solution described here, AS operators signal for each route 544 propagated, if it SHOULD NOT be subsequently propagated to a transit 545 provider or peer. 547 AS path based Outbound Route Filter (ORF) described in 548 [draft-ietf-idr-aspath-orf] is also an interesting complementary 549 technique. It can be used as an automated collaborative messaging 550 system (implemented in BGP) for ISPs to try to develop a complete 551 view of the ASes and AS paths in their CCs. Once an ISP has that 552 view, then AS path filters can be possibly used to detect route 553 leaks. One limitation of this technique is that it cannot duly take 554 into account the fact that routes for prefixes with different 555 business models are often sent over the same link between ASes. 556 Also, the success of AS path based ORF depends on whether ASes at all 557 levels of the hierarchy in a CC participate and provide accurate 558 information (in the ORF messages) about the AS paths they expect to 559 have in their BGP updates. 561 6. Summary 563 It should be emphasized once again that the proposed route-leak 564 detection method using the RLP encoding is not intended to cover all 565 forms of route leaks. However, we feel that the solution covers 566 several important types of route leaks, especially considering some 567 significant route-leak attacks or occurrences that have been 568 frequently observed in recent years. The solution can be implemented 569 in BGP without necessarily tying it to BGPSEC. The proposed solution 570 without BGPSEC can detect and mitigate accidental route leaks, and 571 the same with BGPSEC can detect and mitigate both accidental and 572 malicious route leaks. Carrying the proposed RLP encoding in an 573 optional transitive path attribute in BGP is proposed, but in order 574 to prevent abuse, the RLP encoding would require cryptographic 575 protection. Incorporating the RLP encoding in the BGPSEC Flags field 576 is one way of implementing it securely using an already existing 577 protection mechanism provided in BGPSEC path signatures. 579 7. Security Considerations 581 The proposed Route Leak Protection (RLP) field requires cryptographic 582 protection in order to prevent malicious route leaks. Since it is 583 proposed that the RLP field be included in the Flags field in the 584 Secure_Path Segment in BPGSEC updates, the cryptographic security 585 mechanisms in BGPSEC are expected to also apply to the RLP field. 586 The reader is therefore directed to the security considerations 587 provided in [I-D.ietf-sidr-bgpsec-protocol]. 589 8. IANA Considerations 591 No updates to the registries are suggested by this document. 593 9. Acknowledgements 595 The authors wish to thank Danny McPherson and Eric Osterweil for 596 discussions related to this work. Also, thanks are due to Jared 597 Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff 598 Huston, Randy Bush, Ruediger Volk, Sue Hares, Wes George, Chris 599 Morrow, and Sandy Murphy for comments, suggestions, and critique. 600 The authors are also thankful to Padma Krishnaswamy, Oliver Borchert, 601 and Okhee Kim for their comments and review. 603 10. References 605 10.1. Normative References 607 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 608 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 609 DOI 10.17487/RFC4271, January 2006, 610 . 612 10.2. Informative References 614 [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., 615 and N. Katz-Bassett, "Investigating Interdomain Routing 616 Policies in the Wild", ACM Internet Measurement 617 Conference (IMC), October 2015, 618 . 620 [Cowie2010] 621 Cowie, J., "China's 18 Minute Mystery", Dyn 622 Research/Renesys Blog, November 2010, 623 . 626 [Cowie2013] 627 Cowie, J., "The New Threat: Targeted Internet Traffic 628 Misdirection", Dyn Research/Renesys Blog, November 2013, 629 . 632 [draft-dickson-sidr-route-leak-solns] 633 Dickson, B., "Route Leaks -- Proposed Solutions", IETF 634 Internet Draft (expired), March 2012, 635 . 638 [draft-ietf-idr-aspath-orf] 639 Patel, K. and S. Hares, "AS path Based Outbound Route 640 Filter for BGP-4", IETF Internet Draft (expired), August 641 2007, . 644 [draft-kunzinger-idrp-ISO10747-01] 645 Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)", 646 IETF Internet Draft (expired), November 1994, 647 . 650 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 651 global coordination", IEEE/ACM Transactions on 652 Networking, December 2001, 653 . 656 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of 657 Interdomain Routing Policies", ACM SIGCOMM Computer 658 Communication Review, January 2014, 659 . 661 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in 662 Internet routing - Analysis based on BGP Community data", 663 IEEE ICC 2012, June 2012. 665 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing 666 Large-scale Routing Anomalies: A Case Study of the China 667 Telecom Incident", PAM 2013, March 2013, 668 . 671 [Huston2012] 672 Huston, G., "Leaking Routes", March 2012, 673 . 675 [Huston2014] 676 Huston, G., "What's so special about 512?", September 677 2014, . 679 [I-D.ietf-grow-route-leak-problem-definition] 680 Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 681 and B. Dickson, "Problem Definition and Classification of 682 BGP Route Leaks", draft-ietf-grow-route-leak-problem- 683 definition-03 (work in progress), October 2015. 685 [I-D.ietf-sidr-bgpsec-protocol] 686 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 687 sidr-bgpsec-protocol-13 (work in progress), July 2015. 689 [Kapela-Pilosov] 690 Pilosov, A. and T. Kapela, "Stealing the Internet: An 691 Internet-Scale Man in the Middle Attack", DEFCON-16 Las 692 Vegas, NV, USA, August 2008, 693 . 696 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix 697 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, 698 November 2012, . 701 [Labovitz] 702 Labovitz, C., "Additional Discussion of the April China 703 BGP Hijack Incident", Arbor Networks IT Security Blog, 704 November 2010, 705 . 708 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", 709 Project web page, 2012, 710 . 713 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 714 kc. claffy, "AS Relationships, Customer Cones, and 715 Validation", IMC 2013, October 2013, 716 . 718 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke 719 Today", Dyn Research/Renesys Blog, September 2014, 720 . 723 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project 724 web page, 2014, 725 . 727 [Mauch-nanog] 728 Mauch, J., "Detecting Routing Leaks by Counting", 729 NANOG-41 Albuquerque, NM, USA, October 2007, 730 . 733 [NIST-800-54] 734 Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway 735 Protocol Security", NIST Special Publication 800-54, July 736 2007, . 739 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about 740 How the Internet Works", CloudFare Blog, November 2012, 741 . 744 [proceedings-sixth-ietf] 745 Gross, P., "Proceedings of the April 22-24, 1987 Internet 746 Engineering Task Force", April 1987, 747 . 749 [RFC1105-obsolete] 750 Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 751 (BGP)", IETF RFC (obsolete), June 1989, 752 . 754 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 755 Austein, "BGP Prefix Origin Validation", RFC 6811, 756 DOI 10.17487/RFC6811, January 2013, 757 . 759 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 760 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 761 February 2015, . 763 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August 764 2014, . 767 [Toonk2015-A] 768 Toonk, A., "What caused the Google service interruption", 769 March 2015, . 772 [Toonk2015-B] 773 Toonk, A., "Massive route leak causes Internet slowdown", 774 June 2015, . 777 [Wijchers] 778 Wijchers, B. and B. Overeinder, "Quantitative Analysis of 779 BGP Route Leaks", RIPE-69, November 2014, 780 . 783 [Zmijewski] 784 Zmijewski, E., "Indonesia Hijacks the World", Dyn 785 Research/Renesys Blog, April 2014, 786 . 789 Authors' Addresses 791 Kotikalapudi Sriram 792 US NIST 794 Email: ksriram@nist.gov 796 Doug Montgomery 797 US NIST 799 Email: dougm@nist.gov 801 Brian Dickson 803 Email: brian.peter.dickson@gmail.com 805 Keyur Patel 806 Cisco 808 Email: keyupate@cisco.com 810 Andrei Robachevsky 811 Internet Society 813 Email: robachevsky@isoc.org