idnits 2.17.1 draft-sriram-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. ** 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 249: '...AS3 in Figure 1) SHOULD NOT have forwa...' RFC 2119 keyword, line 277: '... RLP field value SHOULD be set to one ...' RFC 2119 keyword, line 283: '...he prefix-update SHOULD NOT be forward...' RFC 2119 keyword, line 286: '...arios when a sending AS SHOULD set the...' RFC 2119 keyword, line 291: '...bsequent AS path SHOULD NOT forward th...' (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 (July 5, 2015) is 3210 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 18, but not defined == Unused Reference: 'Cowie2010' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'Cowie2013' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'Gao' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'Gill' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'Giotsas' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'Hiran' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'Huston2012' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'Huston2014' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'Kapela-Pilosov' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'Khare' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'Labovitz' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'LRL' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'Luckie' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'Madory' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'Mauch' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'Mauch-nanog' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'Paseka' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'Toonk' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'Wijchers' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'Zmijewski' is defined on line 728, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-grow-route-leak-problem-definition-02 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-12 -- Obsolete informational reference (is this intentional?): RFC 1105 (Obsoleted by RFC 1163) Summary: 3 errors (**), 0 flaws (~~), 24 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: January 6, 2016 B. Dickson 6 Twitter, Inc. 7 July 5, 2015 9 Methods for Detection and Mitigation of BGP Route Leaks 10 draft-sriram-idr-route-leak-detection-mitigation-01 12 Abstract 14 In [I-D.ietf-grow-route-leak-problem-definition], the authors have 15 provided a definition of the route leak problem, and also enumerated 16 several types of route leaks. In this document, we first examine 17 which of those route-leak types are detected and mitigated by the 18 existing origin validation (OV) [RFC 6811] and BGPSEC path validation 19 [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC 20 protocols don't offer a solution, this document suggests an 21 enhancement that would extend the route-leak detection and mitigation 22 capability of BGPSEC. The solution can be implemented in BGP without 23 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC 24 is one way of implementing it in a secure way. We do not claim to 25 have provided a solution for all possible types of route leaks, but 26 the solution covers several, especially considering some significant 27 route-leak attacks or occurrences that have been observed in recent 28 years. The document also includes a stopgap method for detection and 29 mitigation of route leaks for the phase when BGPSEC (path validation) 30 is not yet deployed but only origin validation is deployed. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 6, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 3 68 3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4 69 3.1. Route Leak Protection (RLP) Field Encoding by Sending 70 Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Recommended Actions at a Receiving Router for Detection 72 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8 73 3.2.1. Recommended Actions at a Receiving Router when the 74 Sender is a Customer . . . . . . . . . . . . . . . . 8 75 3.2.2. Recommended Actions at a Receiving Router when the 76 Sender is a Peer . . . . . . . . . . . . . . . . . . 9 77 3.3. Possible Actions at a Receiving Router for Mitigation . . 10 78 4. Stopgap Solution when Only Origin Validation is Deployed . . 10 79 5. Design Rationale and Discussion . . . . . . . . . . . . . . . 11 80 5.1. Is route-leak solution without BGPSEC a serious attack 81 vector? . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2. Comparison with other methods, routing security BCP . . . 12 83 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 10.2. Informative References . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 In [I-D.ietf-grow-route-leak-problem-definition], the authors have 95 provided a definition of the route leak problem, and also enumerated 96 several types of route leaks. In this document, we first examine 97 which of those route-leak types are detected and mitigated by the 98 existing Origin Validation (OV) [RFC6811] and BGPSEC path validation 99 [I-D.ietf-sidr-bgpsec-protocol]. For the rest of this document, we 100 use the term BGPSEC as synonymous with path validation. The BGPSEC 101 protocol provides cryptographic protection for some aspects of BGP 102 update messages. OV and BGPSEC together offer mechanisms to protect 103 against mis-originations and hijacks of IP prefixes as well as man- 104 in-the-middle (MITM) AS path modifications. Route leaks (see 105 [I-D.ietf-grow-route-leak-problem-definition] and references cited at 106 the back) are another type of vulnerability in the global BGP routing 107 system against which OV and BGPSEC so far offer only partial 108 protection. 110 For the types of route leaks enumerated in 111 [I-D.ietf-grow-route-leak-problem-definition], where the current OV 112 and BGPSEC protocols don't offer a solution, this document suggests 113 an enhancement that would extend the detection and mitigation 114 capability of BGPSEC. The solution can be implemented in BGP without 115 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC 116 is one way of implementing it in a secure way. We do not claim to 117 provide a solution for all possible types of route leaks, but the 118 solution covers several relevant types, especially considering some 119 significant route-leak occurrences that have been observed frequently 120 in recent years. The document also includes (in Section 4) a stopgap 121 method for detection and mitigation of route leaks for the phase when 122 BGPSEC (path validation) is not yet deployed but only origin 123 validation is deployed. 125 2. Related Prior Work 127 The basic idea and mechanism embodied in the proposed solution is 128 based on setting an attribute in BGP route announcement to manage the 129 transmission/receipt of the announcement based on the type of 130 neighbor (e.g. customer, provider, etc.). Documented prior work 131 related to said basic idea and mechanism dates back to at least the 132 1980's. Some examples of prior work are: (1) Information flow rules 133 described in [proceedings-sixth-ietf] (see pp. 195-196); (2) Link 134 Type described in [RFC1105-obsolete] (see pp. 4-5); (3) Hierarchical 135 Recording described in [draft-kunzinger-idrp-ISO10747-01] (see 136 Section 6.3.1.12). The problem of route leaks and possible solution 137 mechanisms based on encoding peering-link type information (e.g. p2c, 138 c2p, p2p, etc.) in BGPSEC updates and protecting the same under 139 BGPSEC path signatures have been discussed in IETF SIDR WG at least 140 since 2011. Dickson developed the initial Internet draft of these 141 mechanisms in a BGPSEC context; see 142 [draft-dickson-sidr-route-leak-solns]. The draft expired in 2012. 143 [draft-dickson-sidr-route-leak-solns] defined neighbor relationships 144 on a per link basis, but in the current draft the relationship in 145 encoded per prefix, as prefixes with different business models are 146 often sent over the same link. Also 147 [draft-dickson-sidr-route-leak-solns] proposed a second signature 148 block for the link type encoding, separate from the path signature 149 block in BGPSEC. By contrast, in the current draft when BGPSEC-based 150 solution is considered, cryptographic protection is provided for 151 Route Leak Protection (RLP) encoding using the same signature block 152 as that for path signatures (see Section 3.1). 154 3. Mechanisms for Detection and Mitigation of Route Leaks 156 Referring to the enumeration of route leaks discussed in 157 [I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the 158 route-leak detection capability offered by OV and BGPSEC for 159 different types of route leaks. (Note: Prefix filtering is not 160 considered here in this table. Please see Section 4.) 162 A detailed explanation of the contents of Table 1 is as follows. It 163 is readily observed that route leaks of Types 1, 5, 6, and 7 are not 164 detected by OV or even by BGPSEC. Type 2 route leak involves 165 changing a prefix to a subprefix (i.e. more specific); such a 166 modified update will fail BGPSEC checks. Clearly, Type 3 route leak 167 involves mis-origination or hijacking, and hence can be detected by 168 OV. In the case of Type 3 route leak, there would be no existing 169 ROAs to validate a re-originated prefix or subprefix, but instead a 170 covering ROA would normally exist with the legitimate AS, and hence 171 the update will be considered Invalid by OV. 173 +---------------------------------+---------------------------------+ 174 | Type of Route Leak | Detection Coverage and Comments | 175 +---------------------------------+---------------------------------+ 176 | Type 1: U-Turn with Full Prefix | Neither OV nor BGPSEC (in its | 177 | | current form) detects Type 1. | 178 | ------------------------------- | ------------------------------- | 179 | Type 2: U-Turn with More | In OV, the ROA maxLength may | 180 | Specific Prefix | offer detection of Type 2 in | 181 | | some cases; BGPSEC (in its | 182 | | current form) always detects | 183 | | Type 2. | 184 | ------------------------------- | ------------------------------- | 185 | Type 3: Prefix Mis-Origination | OV by itself detects Type 3; | 186 | with Data Path to Legitimate | BGPSEC does not detect Type 3. | 187 | Origin | | 188 | ------------------------------- | ------------------------------- | 189 | Type 4: Leak of Internal | For internal prefixes never | 190 | Prefixes and Accidental | meant to be seen (i.e. routed) | 191 | Deaggregation | on the Internet, OV helps | 192 | | detect their leak; they might | 193 | | either have no covering ROA or | 194 | | have an AS0-ROA to always | 195 | | filter them. In the case of | 196 | | accidental deaggregation, OV | 197 | | may offer some detection due to | 198 | | ROA maxLength. BGPSEC does not | 199 | | catch Type 4. | 200 | ------------------------------- | ------------------------------- | 201 | Type 5: Lateral ISP-ISP-ISP | Neither OV nor BGPSEC (in its | 202 | Leak | current form) detects Type 5. | 203 | ------------------------------- | ------------------------------- | 204 | Type 6: Leak of Provider | Neither OV nor BGPSEC (in its | 205 | Prefixes to Peer | current form) detects Type 6. | 206 | ------------------------------- | ------------------------------- | 207 | Type 7: Leak of Peer Prefixes | Neither OV nor BGPSEC (in its | 208 | to Provider | current form) detects Type 7. | 209 +---------------------------------+---------------------------------+ 211 Table 1: Examination of Route-Leak Detection Capability of Origin 212 Validation and Current BGPSEC Path Validation 214 In the case of Type 4 leaks involving internal prefixes that are not 215 meant to be routed in the Internet, they are likely to be detected by 216 OV. That is because such prefixes might either have no covering ROA 217 or have an AS0-ROA to always filter them. In the case of Type 4 218 leaks that are due to accidental deaggregation, they may be detected 219 due to violation of ROA maxLength. BGPSEC does not catch Type 4. 220 However, route leaks of Type 4 are least problematic due to the 221 following reasons. In the case of accidental deaggregation, the 222 offending AS is itself the legitimate destination of the leaked more- 223 specific prefixes. Hence, in most cases of this type, the data 224 traffic is neither misrouted not denied service. Also, leaked 225 announcements of Type 4 are short-lived and typically withdrawn 226 quickly following the announcements. Further, the MaxPrefix limit 227 may kick-in in some receiving routers and that helps limit the 228 propagation of sometimes large number of leaked routes of Type 4. 230 Realistically, BGPSEC may take a much longer time being deployed than 231 OV. Hence solution proposals for route leaks should consider both 232 scenarios: (A) OV only (without BGPSEC) and (B) OV plus BGPSEC. 233 Assuming an initial scenario A, and based on the above discussion and 234 Table 1, it is evident that in our proposed solution method, we need 235 to focus primarily on route leaks of Types 1, 2, 5, 6, and 7. In 236 Section 3.1 and Section 3.2, we describe a simple addition to BGP 237 that facilitates detection of route leaks of Types 1, 2, 5, 6, and 7. 238 The simple addition involves a Route Leak Protection (RLP) field, 239 which is carried in an optional transitive path attribute in BGP. 240 When BGPSEC is deployed, the RLP field will be accommodated in the 241 existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is 242 cryptographically protected under path signatures. 244 3.1. Route Leak Protection (RLP) Field Encoding by Sending Router 246 The key principle is that, in the event of a route leak, a receiving 247 router in a provider AS (e.g. referring to Figure 1, ISP2 (AS2) 248 router) should be able to detect from the prefix-update that its 249 customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the 250 update (towards the provider AS). This means that at least one of 251 the ASes in the AS path of the update has indicated that it sent the 252 update to its customer or peer AS, but forbade any subsequent 'Up' 253 forwarding (i.e. from a customer AS to its provider AS). For this 254 purpose, a Route Leak Protection (RLP) field to be set by a sending 255 router is proposed to be used for each AS hop. 257 /\ /\ 258 \ route-leak(P)/ 259 \ propagated / 260 \ / 261 +------------+ peer +------------+ 262 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> 263 / ------------+ prefix(P) +------------+ route-leak(P) 264 | prefix | \ update /\ \ propagated 265 \ (P) / \ / \ 266 ------- prefix(P) \ / \ 267 update \ / \ 268 \ /route-leak(P) \/ 269 \/ / 270 +---------------+ 271 | customer(AS3) | 272 +---------------+ 274 Figure 1: Illustration of the basic notion of a route leak. 276 For the purpose of route leak detection and mitigation proposed in 277 this document, the RLP field value SHOULD be set to one of two values 278 as follows: 280 o 00: This is the default value (i.e. "nothing specified"), 282 o 01: This is the 'Do not Propagate Up' indication; sender 283 indicating that the prefix-update SHOULD NOT be forwarded 'Up' 284 towards a provider AS. 286 There are two different scenarios when a sending AS SHOULD set the 287 '01' indication in a prefix-update: (1) when sending the prefix- 288 update to a customer AS, and (2) to let a peer AS know not to forward 289 the prefix-update 'Up' towards a provide AS. In essence, in both 290 scenarios, the intent of '01' indication is that any receiving AS 291 along the subsequent AS path SHOULD NOT forward the prefix-update 292 'Up' towards its (receiving AS's) provider AS. 294 One may argue for additional RLP indications: for example, '10' to 295 specify 'Propagate to Customers Only', and possibly '11' to signal 296 'Do Not Propagate' (i.e. NO_EXPORT). But in the interest of keeping 297 the methodology simple, the choice of two RLP field values as defined 298 above (00 - default, and 01 - 'Do not Propagate Up') is all that is 299 needed. This two-state specification in the RLP field can be shown 300 to work for detection and mitigation of route leaks of Types 1, 2, 5, 301 6, and 7, which are the focus here (see Section 3.2 and Section 3.3). 303 The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] 304 updates in an optional transitive path attribute. In BGPSEC enabled 305 routers, the RLP encoding SHOULD be accommodated in the existing 306 Flags field in BGPSEC updates. The Flags field is part of the 307 Secure_Path Segment in BPGSEC updates 308 [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags 309 field is available for each AS hop, and currently only the first bit 310 is used in BGPSEC. So there are 7 bits that are currently unused in 311 the Flags field. Two (or more if needed) of these bits can be 312 designated for the RLP field. Since the BGPSEC protocol 313 specification requires a sending AS to include the Flags field in the 314 data that are signed over, the RLP field for each hop (assuming it 315 would be part of the Flags field) will be protected under the sending 316 AS's signature. 318 3.2. Recommended Actions at a Receiving Router for Detection of Route 319 Leaks 321 The recommended receiver actions differ slightly depending on whether 322 the update is received from a customer or a peer. When detecting 323 route leaks of Type 1, 2, and 7, the receiving router is dealing with 324 a customer as the sender. When detecting route leaks of Type 5 and 325 6, the receiving router is dealing with a peer as the sender. 327 3.2.1. Recommended Actions at a Receiving Router when the Sender is a 328 Customer 330 We provide here an example set of receiver actions that work to 331 detect and mitigate route leaks of Types 1, 2, and 7. This example 332 algorithm serves as a proof of concept. However, other receiver 333 algorithms or procedures can be designed (based on the same sender 334 specification as in Section 3.1) and may perform with greater 335 efficacy, and are by no means excluded. 337 A recommended receiver algorithm for detecting a route leak is as 338 follows: 340 A receiving router SHOULD mark an update as a Route-Leak if ALL of 341 the following conditions hold true: 343 1. The update is received from a customer AS. 345 2. It is Valid in accordance with the Origin Validation (OV) and 346 BGPSEC protocols. (Note: BGPSEC validation is not applicable if 347 update is not signed). 349 3. The update has the RLP field set to '01' (i.e. 'Do not Propagate 350 Up') indication for one or more hops (excluding the most recent) 351 in the AS path. 353 The reason for stating "excluding the most recent" in the above 354 algorithm is as follows. The provider AS already knows that the most 355 recent hop in the update is from its customer AS to itself, and it 356 does not need to rely on the RLP field value set by the customer for 357 detection of route leaks. 359 A receiving router expects the RLP field value for any hop in the AS 360 path to be either 00 or 01. However, if a different value (say, 10 361 or 11) is found in the RLP field, then an error condition will get 362 flagged, and any further action is TBD. 364 3.2.2. Recommended Actions at a Receiving Router when the Sender is a 365 Peer 367 The sender and receiver actions described in Section 3.1 and 368 Section 3.2.1 clearly help detect and mitigate route leaks of Types 369 1, 2, and 7. With a slightly modified interpretation of the RLP 370 encoding on the receiver side, they can be extended to detect lateral 371 ISP-ISP-ISP route leaks (Type 5) as well as leaks of provider 372 prefixes to peer (Type 6). (Note: RLP encoding procedure by sending 373 routers remains the same as described in Section 3.1.) 375 A recommended receiver algorithm for an ISP to detect a route leak of 376 either Type 5 or Type 6 is as follows: 378 A receiving BGPSEC router SHOULD mark an update as a Route-Leak if 379 ALL of the following conditions hold true: 381 1. The update is received from a lateral ISP peer. 383 2. It is Valid in accordance with the Origin Validation (OV) and 384 BGPSEC protocols. (Note: BGPSEC validation is not applicable if 385 update is not signed). 387 3. The update has the RLP field set to '01' indication for one or 388 more hops (excluding the most recent) in the AS path. 390 In the above algorithm, the receiving AS interprets the '01' 391 indication slightly strongly (i.e. stronger than in Section 3.2.1) to 392 mean "the update SHOULD NOT have been propagated laterally to a peer 393 ISP like me either". The rationale here is based on the fact that 394 settlement-free ISP peers accept only customer prefix-routes from 395 each other. The receiving AS applies the logic that if a preceding 396 AS (excluding the most recent) set '01' indication, it means that the 397 update was sent to a peer or a customer by the (preceding) AS, and 398 the update should not be traversing a lateral peer-to-peer link 399 subsequently. 401 3.3. Possible Actions at a Receiving Router for Mitigation 403 After applying the above detection algorithm, a receiving router may 404 use any policy-based algorithm of its own choosing to mitigate any 405 detected route leaks. An example receiver algorithm for mitigating a 406 route leak is as follows: 408 o If an update from a customer AS is marked as a Route-Leak, then 409 the receiving router SHOULD prefer a Valid signed update from a 410 peer or an upstream provider over the customer's update. 412 A basic principle here is that the presence of '01' value in the RLP 413 field corresponding to one or more AS hops in the AS path of an 414 update coming from a customer AS informs a receiving router in a 415 provider AS that a route leak is likely occurring. The provider AS 416 then overrides the "prefer customer route" policy, and instead 417 prefers a route learned from a peer or another upstream provider over 418 the customer's route. 420 4. Stopgap Solution when Only Origin Validation is Deployed 422 During a phase when BGPSEC path validation has not yet been deployed 423 but only origin validation has been deployed, it would be good have a 424 stopgap solution for route leaks. The stopgap solution can be in the 425 form of construction of a prefix filter list from ROAs. A suggested 426 procedure for constructing such a list comprises of the following 427 steps: 429 o ISP makes a list of all the ASes (Cust_AS_List) that are in its 430 customer cone (ISP's own AS is also included in the list). (Some 431 of the ASes in Cust_AS_List may be multi-homed to another ISP and 432 that is OK.) 434 o ISP downloads from the RPKI repositories a complete list 435 (Cust_ROA_List) of valid ROAs that contain any of the ASes in 436 Cust_AS_List. 438 o ISP creates a list of all the prefixes (Cust_Prfx_List) that are 439 contained in any of the ROAs in Cust_ROA_List. 441 o Cust_Prfx_List is the allowed list of prefixes that is permitted 442 by the ISP's AS, and will be forwarded by the ISP to upstream 443 ISPs, customers, and peers. 445 o Any prefix not in Cust_Prfx_List but announced by any of the ISP's 446 customers is marked as a potential route leak. Then the ISP's 447 router SHOULD prefer a Valid (i.e. valid according to origin 448 validation) and 'not marked' update from a peer or an upstream 449 provider over the customer's marked update for that prefix. 451 Special considerations with regard to the above procedure may be 452 needed for DDoS mitigation service providers. They typically 453 originate or announce a DDoS victim's prefix to their own ISP on a 454 short notice during a DDoS emergency. Some provisions would need to 455 be made for such cases, and they can be determined with the help of 456 inputs from DDoS mitigation service providers. 458 For developing a list of all the ASes (Cust_AS_List) that are in the 459 customer cone of an ISP, the AS path based Outbound Route Filter 460 (ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see 461 discussion in Section 5.2). 463 5. Design Rationale and Discussion 465 In this section, we will try to provide design justifications for the 466 methodology specified in Section 3, and also answer some anticipated 467 questions. 469 5.1. Is route-leak solution without BGPSEC a serious attack vector? 471 It has been asked if a route-leak solution without BGPSEC, i.e. when 472 RLP bits are not protected, can turn into a serious new attack 473 vector. That answer seems to be: not really! Even the NLRI and 474 AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPSEC seek to 475 fix that. Consider the following. Say, if 99% of route leaks are 476 accidental and 1% are malicious, and if route-leak solution without 477 BGPSEC eliminates the 99%, then perhaps it is worth it (step in the 478 right direction). When BGPSEC comes into deployment, the route leak 479 protection (RLP) bits can be mapped into BGPSEC (using the Flags 480 field) and then necessary security will be in place as well (within 481 each BGPSEC island as and when they emerge). 483 Further, let us consider the worst-case damage that can be caused by 484 maliciously manipulating the RLP bits in an implementation without 485 BGPSEC. An AS that wants to intentionally leak a route would alter 486 the RLP encodings for the preceding hops from '01' (i.e. 'Do not 487 Propagate Up') to '00' (default) wherever applicable. It is true 488 that in that case a receiving router would not be able to detect the 489 leak for the specific prefix-route by the RLP mechanism described 490 here. However, the receiving router may still detect and mitigate it 491 in some cases by applying other means such as prefix filters 492 [RFC7454] and AS path filters [draft-ietf-idr-aspath-orf]. If some 493 malicious leaks go undetected (for RLP without BGPSEC) that is 494 possibly a small price to pay for the ability to detect the bulk of 495 route leaks that are accidental. 497 5.2. Comparison with other methods, routing security BCP 499 It is reasonable to ask if techniques considered in BCPs such 500 as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be 501 adequate to address route leaks. The prefix filtering 502 recommendations in the BCPs may be complementary but not adequate. 503 The difficulty is in ISPs' ability to construct prefix filters that 504 represent their customer cones (CC) accurately, especially when there 505 are many levels in the hierarchy within the CC. In the RLP-encoding 506 based solution described here, AS operators signal for each prefix- 507 route propagated, if it SHOULD NOT be subsequently propagated to a 508 provider/peer. 510 AS path based Outbound Route Filter (ORF) described in 511 [draft-ietf-idr-aspath-orf] is also an interesting complementary 512 technique. It can be used as an automated collaborative messaging 513 system (implemented in BGP) for ISPs to try to develop a complete 514 view of the ASes and AS paths in their CCs. Once an ISP has that 515 view, then AS path filters can be possibly used to detect route 516 leaks. One limitation of this technique is that it cannot duly take 517 into account the fact that prefixes with different business models 518 are often sent over the same link between ASes. Also, the success of 519 it depends on ASes at all levels of the hierarchy in a CC participate 520 and provide accurate information (in the ORF messages) about the AS 521 paths they expect to have in their BGP updates to their provider 522 ISP(s). 524 6. Summary 526 It should be emphasized once again that the proposed route-leak 527 detection method using the RLP encoding is not intended to cover all 528 forms of route leaks. However, we feel that the solution covers 529 several important types of route leaks, especially considering some 530 significant route-leak attacks or occurrences that have been 531 frequently observed in recent years. The solution can be implemented 532 in BGP without necessarily tying it to BGPSEC. The proposed solution 533 without BGPSEC can detect and mitigate accidental route leaks, and 534 the same with BGPSEC can detect and mitigate malicious route leaks as 535 well. Carrying the proposed RLP encoding in an optional transitive 536 path attribute in BGP is proposed, but in order to prevent abuse, the 537 RLP encoding would require cryptographic protection. Incorporating 538 the RLP encoding in the BGPSEC Flags field is one way of implementing 539 it securely using an already existing protection mechanism provided 540 in BGPSEC path signatures. 542 7. Security Considerations 544 The proposed Route Leak Protection (RLP) field requires cryptographic 545 protection in order to prevent malicious route leaks. Since it is 546 proposed that the RLP field be included in the Flags field in the 547 Secure_Path Segment in BPGSEC updates, the cryptographic security 548 mechanisms in BGPSEC are expected to also apply to the RLP field. 549 The reader is therefore directed to the security considerations 550 provided in [I-D.ietf-sidr-bgpsec-protocol]. 552 8. IANA Considerations 554 No updates to the registries are suggested by this document. 556 9. Acknowledgements 558 The authors wish to thank Danny McPherson and Eric Osterweil for 559 discussions related to this work. Also, thanks are due to Jared 560 Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff 561 Huston, Randy Bush, Ruediger Volk, Andrei Robachevsky, Sue Hares, 562 Keyur Patel, Wes George, Chris Morrow, and Sandy Murphy for comments, 563 suggestions, and critique. The authors are also thankful to Padma 564 Krishnaswamy, Oliver Borchert, and Okhee Kim for their comments and 565 review. 567 10. References 569 10.1. Normative References 571 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 572 Protocol 4 (BGP-4)", RFC 4271, January 2006. 574 10.2. Informative References 576 [Cowie2010] 577 Cowie, J., "China's 18 Minute Mystery", Dyn Research/ 578 Renesys Blog, November 2010, 579 . 582 [Cowie2013] 583 Cowie, J., "The New Threat: Targeted Internet Traffic 584 Misdirection", Dyn Research/Renesys Blog, November 2013, 585 . 588 [draft-dickson-sidr-route-leak-solns] 589 Dickson, B., "Route Leaks -- Proposed Solutions", IETF 590 Internet Draft (expired), March 2012, 591 . 594 [draft-ietf-idr-aspath-orf] 595 Patel, K. and S. Hares, "AS path Based Outbound Route 596 Filter for BGP-4", IETF Internet Draft (expired), August 597 2007, . 600 [draft-kunzinger-idrp-ISO10747-01] 601 Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)", 602 IETF Internet Draft (expired), November 1994, 603 . 606 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 607 global coordination", IEEE/ACM Transactions on Networking, 608 December 2001, . 611 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of 612 Interdomain Routing Policies", ACM SIGCOMM Computer 613 Communication Review, January 2014, 614 . 616 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in 617 Internet routing - Analysis based on BGP Community data", 618 IEEE ICC 2012, June 2012, 619 . 622 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing 623 Large-scale Routing Anomalies: A Case Study of the China 624 Telecom Incident", PAM 2013, March 2013, 625 . 628 [Huston2012] 629 Huston, G., "Leaking Routes", March 2012, 630 . 632 [Huston2014] 633 Huston, G., "What's so special about 512?", September 634 2014, . 636 [I-D.ietf-grow-route-leak-problem-definition] 637 Sriram, K., Montgomery, D., McPherson, D., E. 638 Osterweil, and B. Dickson "Problem Definition and Classification of BGP 639 Route Leaks", draft-ietf-grow-route-leak-problem- 640 definition-02 (work in progress), July 2015. 642 [I-D.ietf-sidr-bgpsec-protocol] 643 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 644 sidr-bgpsec-protocol-12 (work in progress), June 2015. 646 [Kapela-Pilosov] 647 Pilosov, A. and T. Kapela, "Stealing the Internet: An 648 Internet-Scale Man in the Middle Attack", DEFCON-16 Las 649 Vegas, NV, USA, August 2008, 650 . 653 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix 654 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, 655 November 2012, . 658 [Labovitz] 659 Labovitz, C., "Additional Discussion of the April China 660 BGP Hijack Incident", Arbor Networks IT Security Blog, 661 November 2010, 662 . 665 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", 666 Project web page, 2012, 667 . 670 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 671 kc. claffy, "AS Relationships, Customer Cones, and 672 Validation", IMC 2013, October 2013, 673 . 675 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke 676 Today", Dyn Research/Renesys Blog, September 2014, 677 . 680 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project 681 web page, 2014, 682 . 684 [Mauch-nanog] 685 Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41 686 Albuquerque, NM, USA, October 2007, 687 . 690 [NIST-800-54] 691 Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway 692 Protocol Security", NIST Special Publication 800-54, July 693 2007, . 696 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about 697 How the Internet Works", CloudFare Blog, November 2012, 698 . 701 [proceedings-sixth-ietf] 702 Gross, P., "Proceedings of the April 22-24, 1987 Internet 703 Engineering Task Force", April 1987, 704 . 706 [RFC1105-obsolete] 707 Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 708 (BGP)", IETF RFC (obsolete), June 1989, 709 . 711 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 712 Austein, "BGP Prefix Origin Validation", RFC 6811, January 713 2013. 715 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 716 and Security", BCP 194, RFC 7454, February 2015. 718 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August 719 2014, . 722 [Wijchers] 723 Wijchers, B. and B. Overeinder, "Quantitative Analysis of 724 BGP Route Leaks", RIPE-69, November 2014, 725 . 728 [Zmijewski] 729 Zmijewski, E., "Indonesia Hijacks the World", Dyn 730 Research/Renesys Blog, April 2014, 731 . 734 Authors' Addresses 736 Kotikalapudi Sriram 737 US NIST 739 Email: ksriram@nist.gov 741 Doug Montgomery 742 US NIST 744 Email: dougm@nist.gov 746 Brian Dickson 747 Twitter, Inc. 749 Email: bdickson@twitter.com