idnits 2.17.1 draft-ietf-idr-route-leak-detection-mitigation-07.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 ([RFC6811]), 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 289: '...hen this information SHOULD be used to...' RFC 2119 keyword, line 335: '...all AS operators SHOULD implement the ...' RFC 2119 keyword, line 361: '... the route MUST NOT be sent to a tra...' RFC 2119 keyword, line 375: '...AS3 in Figure 1) SHOULD NOT have forwa...' RFC 2119 keyword, line 404: '... RLP field value SHOULD be set to one ...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2017) is 2414 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 21, but not defined == Unused Reference: 'Cowie2010' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'Cowie2013' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'Gill' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'Hiran' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'Huston2012' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'Huston2014' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'Kapela-Pilosov' is defined on line 972, but no explicit reference was found in the text == Unused Reference: 'Kephart' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'Khare' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'Labovitz' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'LRL' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'Madory' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'Mauch' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'Mauch-nanog' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'Paseka' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'Sriram' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'Toonk' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'Toonk2015-A' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: 'Toonk2015-B' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'Zmijewski' is defined on line 1094, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-01 -- 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: March 10, 2018 B. Dickson 7 K. Patel 8 Arrcus 9 A. Robachevsky 10 Internet Society 11 September 6, 2017 13 Methods for Detection and Mitigation of BGP Route Leaks 14 draft-ietf-idr-route-leak-detection-mitigation-07 16 Abstract 18 RFC 7908 provides a definition of the route leak problem, and also 19 enumerates several types of route leaks. This document first 20 examines which of those route-leak types are detected and mitigated 21 by the existing origin validation (OV) [RFC 6811]. It is recognized 22 that OV offers a limited detection and mitigation capability against 23 route leaks. This document specifies enhancements that significantly 24 extend the route-leak prevention, detection, and mitigation 25 capabilities of BGP. One solution component involves intra-AS 26 messaging from ingress router to egress router using a BGP Community 27 or Attribute. This intra-AS messaging prevents the AS from causing 28 route leaks. Another solution component involves carrying a per-hop 29 route-leak protection (RLP) field in BGP updates. The RLP fields are 30 proposed to be carried in a new optional transitive attribute, called 31 BGP RLP attribute. The RLP attribute helps with detection and 32 mitigation of route leaks at ASes downstream from the leaking AS. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 10, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 4 69 3. Do Origin Validation and BGPsec Assist in Route-Leak 70 Detection? . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Mechanisms for Prevention, Detection and Mitigation of Route 72 Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Ascertaining Peering Relationship . . . . . . . . . . . . 6 74 4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging 7 75 4.2.1. Non-Transitive BGP Community for Intra-AS Messaging . 7 76 4.2.2. Non-Transitive BGP pRLP Attribute for Intra-AS 77 Messaging . . . . . . . . . . . . . . . . . . . . . . 8 78 4.3. Route-Leak Protection (RLP) Field Encoding by Sending 79 Router . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3.1. BGP RLP Attribute . . . . . . . . . . . . . . . . . . 10 81 4.3.2. Carrying RLP Field Values in the BGPsec Flags . . . . 11 82 4.4. Recommended Actions at a Receiving Router for Detection 83 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 11 84 4.5. Possible Actions at a Receiving Router for Mitigation . . 12 85 5. Stopgap Solution when Only Origin Validation is Deployed . . 12 86 6. Design Rationale and Discussion . . . . . . . . . . . . . . . 13 87 6.1. Is route-leak solution without cryptographic protection a 88 serious attack vector? . . . . . . . . . . . . . . . . . 13 89 6.2. Combining results of route-leak detection, OV and BGPsec 90 validation for path selection decision . . . . . . . . . 15 91 6.3. Are there cases when valley-free violations can be 92 considered legitimate? . . . . . . . . . . . . . . . . . 15 93 6.4. Comparison with other methods (routing security BCPs) . . 16 94 6.5. Per-Hop RLP Field or Single RLP Flag per Update? . . . . 16 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 100 10.2. Informative References . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 [RFC7908] provides a definition of the route leak problem, and also 106 enumerates several types of route leaks. This document first 107 examines which of those route-leak types are detected and mitigated 108 by the existing Origin Validation (OV) [RFC6811] method. OV and 109 BGPsec path validation [I-D.ietf-sidr-bgpsec-protocol] together offer 110 mechanisms to protect against re-originations and hijacks of IP 111 prefixes as well as man-in-the-middle (MITM) AS path modifications. 112 Route leaks (see [RFC7908] and references cited at the back) are 113 another type of vulnerability in the global BGP routing system 114 against which OV offers only partial protection. BGPsec (i.e. path 115 validation) provides cryptographic protection for some aspects of BGP 116 update messages, but in its current form BGPsec doesn't offer any 117 protection against route leaks. 119 For the types of route leaks enumerated in [RFC7908], where the OV 120 method does not offer a solution, this document specifies 121 enhancements that significantly extend the route-leak prevention, 122 detection, and mitigation capabilities of BGP. One solution 123 component involves intra-AS messaging from ingress router to egress 124 router using a BGP Community or Attribute. This intra-AS messaging 125 prevents the AS from causing route leaks. Another solution component 126 involves carrying a per-hop route-leak protection (RLP) field in BGP 127 updates. The RLP fields are proposed to be carried in a new optional 128 transitive attribute, called BGP RLP attribute. The RLP attribute 129 helps with detection and mitigation of route leaks at ASes downstream 130 from the leaking AS. 132 The solution is meant to be initially implemented as an enhancement 133 of BGP without requiring BGPsec. However, when BGPsec is deployed in 134 the future, the solution can be incorporated in BGPsec, enabling 135 cryptographic protection for the RLP field. That would be one way of 136 implementing the proposed solution in a secure way. It is not 137 claimed that the solution detects all possible types of route leaks 138 but it detects several types, especially considering some significant 139 route-leak occurrences that have been observed in recent years. The 140 document also includes a stopgap method (in Section 5) for detection 141 and mitigation of route leaks for an intermediate phase when OV is 142 deployed but BGP protocol on the wire is unchanged. 144 2. Related Prior Work 146 A mechanism embodied in the proposed solution is based on setting an 147 attribute in BGP route announcement to manage the transmission/ 148 receipt of the announcement based on the type of neighbor (e.g. 149 customer, transit provider, etc.). Documented prior work related to 150 said basic idea and mechanism dates back to at least the 1980's. 151 Some examples of prior work are: (1) Information flow rules described 152 in [proceedings-sixth-ietf] (see pp. 195-196); (2) Link Type 153 described in [RFC1105-obsolete] (see pp. 4-5); (3) Hierarchical 154 Recording described in [draft-kunzinger-idrp-ISO10747-01] (see 155 Section 6.3.1.12). The problem of route leaks and possible solution 156 mechanisms based on encoding peering-link type information, e.g. P2C 157 (i.e. Transit-Provider to Customer), C2P (i.e. Customer to Transit- 158 Provider), p2p (i.e. peer to peer) etc., in BGPsec updates and 159 protecting the same under BGPsec path signatures have been discussed 160 in IETF SIDR WG at least since 2011. 161 [draft-dickson-sidr-route-leak-solns] attempted to describe these 162 mechanisms in a BGPsec context. The draft expired in 2012. 163 [draft-dickson-sidr-route-leak-solns] defined neighbor relationships 164 on a per link basis, but in the current document the relationship is 165 encoded per prefix, as routes for prefixes with different peering 166 relationships may be sent over the same link. Also 167 [draft-dickson-sidr-route-leak-solns] proposed a second signature 168 block for the link type encoding, separate from the path signature 169 block in BGPsec. By contrast, in the current document when BGPsec- 170 based solution is considered, cryptographic protection is provided 171 for Route-Leak Protection (RLP) encoding using the same signature 172 block as that for path signatures (see Section 4.3.2). 174 3. Do Origin Validation and BGPsec Assist in Route-Leak Detection? 176 Referring to the enumeration of route leaks discussed in [RFC7908], 177 Table 1 summarizes the route-leak detection capability offered by OV 178 and BGPsec for different types of route leaks. (Note: Prefix 179 filtering is not considered here in this table. Please see 180 Section 5.) 182 A detailed explanation of the contents of Table 1 is as follows. It 183 is readily observed that route leaks of Types 1, 2, 3, and 4 are not 184 detected by OV or BGPsec in its current form. Clearly, Type 5 route 185 leak involves re-origination or hijacking, and hence can be detected 186 by OV. In the case of Type 5 route leak, there would be no existing 187 ROAs to validate a re-originated prefix or more specific, but instead 188 a covering ROA would normally exist with the legitimate AS, and hence 189 the update will be considered Invalid by OV. 191 +---------------------------------+---------------------------------+ 192 | Type of Route Leak | Current State of Detection | 193 | | Coverage | 194 +---------------------------------+---------------------------------+ 195 | Type 1: Hairpin Turn with Full | Neither OV nor BGPsec (in its | 196 | Prefix | current form) detects Type 1. | 197 | ------------------------------- | ------------------------------- | 198 | Type 2: Lateral ISP-ISP-ISP | Neither OV nor BGPsec (in its | 199 | Leak | current form) detects Type 2. | 200 | ------------------------------- | ------------------------------- | 201 | Type 3: Leak of Transit- | Neither OV nor BGPsec (in its | 202 | Provider Prefixes to Peer | current form) detects Type 3. | 203 | ------------------------------- | ------------------------------- | 204 | Type 4: Leak of Peer Prefixes | Neither OV nor BGPsec (in its | 205 | to Transit Provider | current form) detects Type 4. | 206 | ------------------------------- | ------------------------------- | 207 | Type 5: Prefix Re-Origination | OV detects Type 5. | 208 | with Data Path to Legitimate | | 209 | Origin | | 210 | ------------------------------- | ------------------------------- | 211 | Type 6: Accidental Leak of | For internal prefixes never | 212 | Internal Prefixes and More | meant to be routed on the | 213 | Specifics | Internet, OV helps detect their | 214 | | leak; they might either have no | 215 | | covering ROA or have an AS0-ROA | 216 | | to always filter them. In the | 217 | | case of accidental leak of more | 218 | | specifics, OV may offer some | 219 | | detection due to ROA maxLength. | 220 +---------------------------------+---------------------------------+ 222 Table 1: Examination of Route-Leak Detection Capability of Origin 223 Validation and Current BGPsec Path Validation 225 In the case of Type 6 leaks involving internal prefixes that are not 226 meant to be routed in the Internet, they are likely to be detected by 227 OV. That is because such prefixes might either have no covering ROA 228 or have an AS0-ROA to always filter them. In the case of Type 6 229 leaks that are due to accidental leak of more specifics, they may be 230 detected due to violation of ROA maxLength. BGPsec (i.e. path 231 validation) in its current form does not detect Type 6. However, 232 route leaks of Type 6 are least problematic due to the following 233 reasons. In the case of leak of more specifics, the offending AS is 234 itself the legitimate destination of the leaked more-specific 235 prefixes. Hence, in most cases of this type, the data traffic is 236 neither misrouted not denied service. Also, leaked announcements of 237 Type 6 are short-lived and typically withdrawn quickly following the 238 announcements. Further, the MaxPrefix limit may kick-in in some 239 receiving routers and that helps limit the propagation of sometimes 240 large number of leaked routes of Type 6. 242 Realistically, BGPsec may take a much longer time being deployed than 243 OV. Hence solution proposals for route leaks should consider both 244 scenarios: (A) OV only (without BGPsec) and (B) OV plus BGPsec. 245 Assuming an initial scenario A, and based on the above discussion and 246 Table 1, it is evident that the solution method should focus 247 primarily on route leaks of Types 1, 2, 3, and 4. 249 4. Mechanisms for Prevention, Detection and Mitigation of Route Leaks 251 There are two considerations for route leaks: (1) Prevention of route 252 leaks from a local AS, and (2) Detection and mitigation of route 253 leaks in ASes that are downstream from the leaking AS. 255 In Section 4.1, the method of ascertaining peering relationship per 256 prefix is described. Section 4.2 describes intra-AS messaging 257 methods for prevention of route leaks from local AS. Section 4.3 and 258 Section 4.4 describe a simple addition to BGP that facilitates 259 detection and mitigation of route leaks of Types 1, 2, 3, and 4 (see 260 Section 3) at an downstream AS from the leaking AS. 262 4.1. Ascertaining Peering Relationship 264 There are four possible peering relationships (i.e. roles) an AS can 265 have with a neighbor AS: (1) Provider: transit-provider for all 266 prefixes exchanged, (2) Customer: customer for all prefixes 267 exchanged, (3) Lateral Peer: lateral peer (i.e. non-transit) for all 268 prefixes exchanged, and (4) Complex: different relationships for 269 different sets of prefixes [Luckie]. On a per-prefix basis, the 270 peering role types simplify to provider, customer, or lateral peer. 272 Operators rely on some form of out-of-band (OOB) (i.e. external to 273 BGP) communication to exchange information about their peering 274 relationship, AS number, interface IP address, etc. If the 275 relationship is complex, the OOB communication also includes the sets 276 of prefixes for which they have different roles. 277 [I-D.ietf-idr-bgp-open-policy] introduces a method of re-confirming 278 the BGP Role during BGP OPEN messaging (except when the role is 279 complex). It defines a new BGP Role capability, which helps in re- 280 confirming the relationship when it is provider, customer, or lateral 281 peer. BGP Role does not replace the OOB communication since it 282 relies on the OOB communication to set the role type in the BGP OPEN 283 message. However, BGP Role provides a means to double check, and if 284 there is a contradiction detected via the BGP Role messages, then a 285 Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy]. 287 When the BGP relationship information has been correctly exchanged 288 (i.e. free of contradictions) including the sets of prefixes with 289 different roles (if complex), then this information SHOULD be used to 290 set the role per-prefix with each peer. For example, if the local 291 AS's role is Provider with a neighbor AS, then the per-prefix role is 292 set to 'Provider' for all prefixes sent to the neighbor, and set to 293 'Customer' for all prefixes received from the neighbor. 295 4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging 297 Note: The intra-AS messaging for route leak prevention can be done 298 using non-transitive BGP Community or Attribute. Both options are 299 described below; one of them will be chosen after IDR working group 300 consensus is established. 302 4.2.1. Non-Transitive BGP Community for Intra-AS Messaging 304 The following procedure (or similar) for intra-AS messaging (i.e. 305 between ingress and egress routers) for prevention of route leaks is 306 a fairly common practice used by large ISPs. (Note: This information 307 was gathered from discussions on the NANOG mailing list 308 [Nanog-thread-June2016] as well as through private discussions with 309 operators of large ISP networks.) 311 Routes are tagged on ingress to an AS with communities for origin, 312 including the type of eBGP peer it was learned from (customer, 313 provider or lateral peer), geographic location, etc. The community 314 attributes are carried across the AS with the routes. Routes that 315 the AS originates directly are tagged with similar origin communities 316 when they are redistributed into BGP from static, IGP, etc. These 317 communities are used along with additional logic in route policies to 318 determine which routes are to be announced to which eBGP peers and 319 which are to be dropped. Route policy is applied to eBGP sessions 320 based on what set of routes they should receive (transit, full 321 routes, internal-only, default-only, etc.). In this process, the 322 ISP's AS also ensures that routes learned from a transit-provider or 323 a lateral peer (i.e. non-transit) at an ingress router are not leaked 324 at an egress router to another transit-provider or lateral peer. 326 Additionally, in many cases, ISP network operators' outbound policies 327 require explicit matches for expected communities before passing 328 routes. This helps ensure that that if an update has made it into 329 the routing table (i.e. RIB) but has missed its ingress community 330 tagging (due to a missing/misapplied ingress policy), it will not be 331 inadvertently leaked. 333 The above procedure (or a simplified version of it) is also 334 applicable when an AS consists of a single eBGP router. It is 335 recommended that all AS operators SHOULD implement the procedure 336 described above (or similar that is appropriate for their network) to 337 prevent route leaks that they have direct control over. 339 4.2.2. Non-Transitive BGP pRLP Attribute for Intra-AS Messaging 341 It is possible to use an optional non-transitive BGP Attribute 342 instead of the Community described above for intra-AS messaging for 343 route leak prevention. The following description would be used in 344 case the IDR working group decides on using a BGP Attribute. 346 A new optional non-transitive BGP Attribute called Preventive Route 347 Leak Protection (pRLP) is used. The attribute type code for the pRLP 348 attribute is to be assigned by IANA. The length of this attribute is 349 0 as it is used only as a flag. 351 Ingress (receiving) router action: The decision to set or not set the 352 pRLP flag is made by a receiving router upon a route ingress. The 353 flag is set when the route is received from a provider or a lateral 354 peer. The flag is not set when the route is received from a 355 customer. When the relationship is complex, the flag is set based on 356 the per-prefix peering role information (see Section 4.1). 358 Egress (sending) router action: A sending router is allowed to send a 359 route without the pRLP flag to any neighbor (transit-provider, 360 customer, lateral peer). However, if the pRLP flag is present, then 361 the route MUST NOT be sent to a transit-provider or a lateral peer. 363 An AS that follows the above set of receiver (ingress) and sender 364 (egress) actions, prevents itself from causing route leaks. 366 4.3. Route-Leak Protection (RLP) Field Encoding by Sending Router 368 This section, Section 4.4 and Section 4.5 describe methods of 369 detection and mitigation of route leaks in an AS downstream from the 370 leaking AS. 372 The key principle is that, in the event of a route leak, a receiving 373 router in a transit-provider AS (e.g. referring to Figure 1, ISP2 374 (AS2) router) should be able to detect from the update message that 375 its customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the 376 update (towards the transit-provider AS). This means that at least 377 one of the ASes in the AS path of the update has indicated that it 378 sent the update to its customer or lateral (i.e. non-transit) peer, 379 but forbade any subsequent 'Up' forwarding (i.e. from a customer AS 380 to its transit-provider AS). For this purpose, a Route-Leak 381 Protection (RLP) field to be set by a sending router is proposed to 382 be used for each AS hop. 384 /\ /\ 385 \ route-leak(P)/ 386 \ propagated / 387 \ / 388 +------------+ peer +------------+ 389 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> 390 / ------------+ prefix(P) +------------+ route-leak(P) 391 | prefix | \ update /\ \ propagated 392 \ (P) / \ / \ 393 ------- prefix(P) \ / \ 394 update \ / \ 395 \ /route-leak(P) \/ 396 \/ / 397 +---------------+ 398 | customer(AS3) | 399 +---------------+ 401 Figure 1: Illustration of the basic notion of a route leak. 403 For the purpose of route-leak detection and mitigation proposed in 404 this document, the RLP field value SHOULD be set to one of two values 405 as follows: 407 o 0: This is the default value (i.e. "nothing specified"), 409 o 1: This is the 'Do not Propagate Up or Lateral' indication; sender 410 indicating that the route SHOULD NOT be forwarded 'Up' towards a 411 transit-provider AS or to a lateral (i.e. non-transit) peer AS. 413 The RLP indications SHOULD be set on a per prefix basis. This is 414 because some peering relations between neighbors can be complex (see 415 Section 4.1). Further, the RLP indications are set on a per-hop 416 (i.e. per AS) basis. 418 There are two different scenarios when a sending AS SHOULD set value 419 1 in the RLP field: (a) when sending the update to a customer AS, and 420 (b) when sending the update to a lateral peer (i.e. non-transit) AS. 421 In essence, in both scenarios, the intent of RLP = 1 is that the 422 neighbor AS and any receiving AS along the subsequent AS path SHOULD 423 NOT forward the update 'Up' towards its (receiving AS's) transit- 424 provider AS or laterally towards its peer (i.e. non-transit) AS. 426 When sending an update 'Up' to a transit-provider AS, the RLP 427 encoding SHOULD be set to the default value of 0. When a sending AS 428 sets the RLP encoding to 0, it is indicating to the receiving AS that 429 the update can be propagated in any direction (i.e. towards transit- 430 provider, customer, or lateral peer). 432 The two-state specification in the RLP field (as described above) 433 works for detection and mitigation of route leaks of Types 1, 2, 3, 434 and 4 which are the focus here (see Section 4.4 and Section 4.5). 436 An AS MUST NOT rewrite/reset the values set by any preceding ASes in 437 their respective RLP fields. 439 The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] 440 updates in a new BGP optional transitive attribute (see 441 Section 4.3.1). In BGPsec, it SHOULD be carried in the Flags field 442 (see Section 4.3.2). 444 4.3.1. BGP RLP Attribute 446 The BGP RLP attribute is a new BGP optional transitive attribute. 447 The attribute type code for the RLP attribute is to be assigned by 448 IANA. The length field of this attribute is 2 octets. The value 449 field of the RLP attribute is defined as a set of one or more pairs 450 of ASN (4 octets) and RLP (one octet) fields as described below 451 (Figure 2). 453 +-----------------------+ -\ 454 | ASN: N | | 455 +-----------------------+ > (Most recently added) 456 | RLP: N | | 457 +-----------------------+ -/ 458 ........... 459 +-----------------------+ -\ 460 | ASN: 1 | | 461 +-----------------------+ > (Least recently added) 462 | RLP: 1 | | 463 +-----------------------+ -/ 465 Figure 2: BGP RLP Attribute format. 467 The RLP Attribute value is a sequence of these two components (see 468 Figure 2): 470 ASN: Four octets encoding the public registered AS number of a BGP 471 speaker. 473 RLP Field: One octet encoding the RLP Field bits. The value of the 474 RLP Field octet can be 0 (decimal) or 1 (decimal) as described above 475 in Section 4.3.1. Its usage will be further discussed in subsequent 476 sections. 478 If all ASes in the AS_PATH of a route are upgraded to participate in 479 RLP, then the ASNs in the RLP TLV in Figure 2 will correspond one-to- 480 one with sequence of ASes in the AS_PATH (excluding prepends). If 481 some ASes do not participate, then one or more {ASN, RLP} tuples may 482 be missing in the RLP attribute relative to the AS_PATH. 484 4.3.2. Carrying RLP Field Values in the BGPsec Flags 486 In BGPsec enabled routers, the RLP encoding SHOULD be accommodated in 487 the existing Flags field in BGPsec updates. The Flags field is part 488 of the Secure_Path Segment in BGPsec updates 489 [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags 490 field is available for each AS hop, and currently only the first bit 491 is used in BGPsec. So there are 7 bits that are currently unused in 492 the Flags field. One of these bits can be designated for the RLP 493 field value (see Section 4.3.1). This bit can be set to 0 when the 494 RLP Field value is 0 and set to 1 when the RLP Field value is 1. 495 Since the BGPsec protocol specification requires a sending AS to 496 include the Flags field in the data that are signed over, the RLP 497 field for each hop (assuming it would be part of the Flags field as 498 described) will be protected under the sending AS's signature. 500 4.4. Recommended Actions at a Receiving Router for Detection of Route 501 Leaks 503 The following receiver algorithm is RECOMMENDED for detecting route 504 leaks: 506 A receiving router MUST mark an update as a 'Route Leak' if ALL of 507 the following conditions hold true: 509 1. The update is received from a customer or lateral peer AS. 511 2. The update has the RLP Field set to 1 (i.e. 'Do not Propagate Up 512 or Lateral') indication for one or more hops (excluding the most 513 recent) in the AS path. 515 The reason for stating "excluding the most recent" in the above 516 algorithm is as follows. An ISP should look at RLP values set by 517 ASes preceding the immediate sending AS in order to ascertain a leak. 518 The receiving router already knows that the most recent hop in the 519 update is from its customer or lateral-peer AS to itself, and it does 520 not need to rely on the RLP field value set by that AS (i.e the 521 immediate neighbor AS in the AS path) for detection of route leaks. 523 If the RLP encoding is secured by BGPsec (see Section 4.3) and hence 524 protected against tampering by intermediate ASes, then there would be 525 added certainty in the route-leak detection algorithm described above 526 (see discussions in Section 6.1 and Section 6.2). 528 4.5. Possible Actions at a Receiving Router for Mitigation 530 After applying the above detection algorithm, a receiving router may 531 use any policy-based algorithm of its own choosing to mitigate any 532 detected route leaks. An example receiver algorithm for mitigating a 533 route leak is as follows: 535 o If an update from a customer or lateral peer AS is marked as a 536 'Route Leak' (see Section 4.4), then the receiving router SHOULD 537 prefer an alternate unmarked route. 539 o If no alternate unmarked route is available, then a route marked 540 as a 'Route Leak' MAY be accepted. 542 A basic principle here is that if an AS receives and marks a customer 543 route as 'Route Leak', then the AS should override the "prefer 544 customer route" policy, and instead prefer an alternate 'clean' route 545 learned from another customer, a lateral peer, or a transit provider. 546 This can be implemented by adjusting the local preference for the 547 routes in consideration. 549 5. Stopgap Solution when Only Origin Validation is Deployed 551 A stopgap method is described here for detection and mitigation of 552 route leaks for the intermediate phase when OV is deployed but BGP 553 protocol on the wire is unchanged. The stopgap solution can be in 554 the form of construction of a prefix filter list from ROAs. A 555 suggested procedure for constructing such a list comprises of the 556 following steps: 558 o ISP makes a list of all the ASes (Cust_AS_List) that are in its 559 customer cone (ISP's own AS is also included in the list). (Some 560 of the ASes in Cust_AS_List may be multi-homed to another ISP and 561 that is OK.) 563 o ISP downloads from the RPKI repositories a complete list 564 (Cust_ROA_List) of valid ROAs that contain any of the ASes in 565 Cust_AS_List. 567 o ISP creates a list of all the prefixes (Cust_Prfx_List) that are 568 contained in any of the ROAs in Cust_ROA_List. 570 o Cust_Prfx_List is the allowed list of prefixes that is permitted 571 by the ISP's AS, and will be forwarded by the ISP to upstream 572 ISPs, customers, and peers. 574 o A route for a prefix that is not in Cust_Prfx_List but announced 575 by one of ISP's customers is 'marked' as a potential route leak. 576 Further, the ISP's router SHOULD prefer an alternate route that is 577 Valid (i.e. valid according to origin validation) and 'clean' 578 (i.e. not marked) over the 'marked' route. The alternate route 579 may be from a peer, transit provider, or different customer. 581 Special considerations with regard to the above procedure may be 582 needed for DDoS mitigation service providers. They typically 583 originate or announce a DDoS victim's prefix to their own ISP on a 584 short notice during a DDoS emergency. Some provisions would need to 585 be made for such cases, and they can be determined with the help of 586 inputs from DDoS mitigation service providers. 588 For developing a list of all the ASes (Cust_AS_List) that are in the 589 customer cone of an ISP, the AS path based Outbound Route Filter 590 (ORF) technique [I-D.ietf-idr-aspath-orf] can be helpful (see 591 discussion in Section 6.4). 593 Another technique based on AS_PATH filters is described in 594 [Snijders]. This method is applicable to very large ISPs (i.e. big 595 networks) that have lateral peering. For a pair of such very large 596 ISPs, say A and B, the method depends on ISP A communicating out-of- 597 band (e.g. by email) with ISP B about whether or not it (ISP A) has 598 any transit providers. This out-of-band knowledge enables ISP B to 599 apply suitable AS_PATH filtering criteria for routes involving the 600 presence of ISP A in the path and prevent certain kinds of route 601 leaks (see [Snijders] for details). 603 6. Design Rationale and Discussion 605 This section provides design justifications for the methodology 606 specified in Section 4, and also answers some questions that are 607 anticipated or have been raised in the IETF IDR and SIDR working 608 group meetings. 610 6.1. Is route-leak solution without cryptographic protection a serious 611 attack vector? 613 It has been asked if a route-leak solution without BGPsec, i.e. when 614 RLP Fields are not protected, can turn into a serious new attack 615 vector. The answer seems to be: not really! Even the NLRI and 616 AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPsec seek to 617 fix that. Consider the following. Say, if 99% of route leaks are 618 accidental and 1% are malicious, and if route-leak solution without 619 BGPsec eliminates the 99%, then perhaps it is worth it (step in the 620 right direction). When BGPsec comes into deployment, the route-leak 621 protection (RLP) bits can be mapped into BGPsec (using the Flags 622 field) and then necessary security will be in place as well (within 623 each BGPsec island as and when they emerge). 625 Further, let us consider the worst-case damage that can be caused by 626 maliciously manipulating the RLP Field values in an implementation 627 without cryptographic protection (i.e. sans BGPsec). Manipulation of 628 the RLP bits can result in one of two types of attacks: (a) Upgrade 629 attack and (b) Downgrade attack. Descriptions and discussions about 630 these attacks follow. In what follows, P2C stands for transit 631 provider to customer (Down); C2P stands for customer to transit 632 provider (Up), and p2p stands for peer to peer (lateral or non- 633 transit relationship). 635 (a) Upgrade attack: An AS that wants to intentionally leak a route 636 would alter the RLP encodings for the preceding hops from 1 (i.e. 637 'Do not Propagate Up or Lateral') to 0 (default) wherever applicable. 638 This poses no problem for a route that keeps propagating in the 639 'Down' (P2C) direction. However, for a route that propagates 'Up' 640 (C2P) or 'Lateral' (p2p), the worst that can happen is that a route 641 leak goes undetected. That is, a receiving router would not be able 642 to detect the leak for the route in question by the RLP mechanism 643 described here. However, the receiving router may still detect and 644 mitigate it in some cases by applying other means such as prefix 645 filters [RFC7454]. If some malicious leaks go undetected (when RLP 646 is deployed without BGPsec) that is possibly a small price to pay for 647 the ability to detect the bulk of route leaks that are accidental. 649 (b) Downgrade attack: RLP encoding is set to 1 (i.e. 'Do not 650 Propagate Up or Lateral') when it should be set to 0 (default). This 651 would result in a route being mis-detected and marked as a route 652 leak. By default RLP encoding is set to 0, and that helps reduce 653 errors of this kind (i.e. accidental downgrade incidents). Every AS 654 or ISP wants reachability for prefixes it originates and for its 655 customer prefixes. So an AS or ISP is not likely to change an RLP 656 value 0 to 1 intentionally. If a route leak is detected (due to 657 intentional or accidental downgrade) by a receiving router, it would 658 prefer an alternate 'clean' route from a transit provider or peer 659 over a 'marked' route from a customer. It may end up with a 660 suboptimal path. In order to have reachability, the receiving router 661 would accept a 'marked' route if there is no alternative that is 662 'clean'. So RLP downgrade attacks (intentional or accidental) would 663 be quite rare, and the consequences do not appear to be grave. 665 6.2. Combining results of route-leak detection, OV and BGPsec 666 validation for path selection decision 668 Combining the results of route-leak detection, OV, and BGPsec 669 validation for path selection decision is up to local policy in a 670 receiving router. As an example, a router may always give precedence 671 to outcomes of OV and BGPsec validation over that of route-leak 672 detection. That is, if an update fails OV or BGPsec validation, then 673 the update is not considered a candidate for path selection. 674 Instead, an alternate update is chosen that passed OV and BGPsec 675 validation and additionally was not marked as route leak. 677 If only OV is deployed (and not BGPsec), then there are six possible 678 combinations between OV and route-leak detection outcomes. Because 679 there are three possible outcomes for OV (NotFound, Valid, and 680 Invalid) and two possible outcomes for route-leak detection (marked 681 as leak and not marked). If OV and BGPsec are both deployed, then 682 there are twelve possible combinations between OV, BGPsec validation, 683 and route-leak detection outcomes. As stated earlier, since BGPsec 684 protects the RLP encoding, there would be added certainty in route- 685 leak detection outcome if an update is BGPsec valid (see 686 Section 6.1). 688 6.3. Are there cases when valley-free violations can be considered 689 legitimate? 691 There are studies in the literature [Anwar] [Giotsas] [Wijchers] 692 observing and analyzing the behavior of routes announced in BGP 693 updates using data gathered from the Internet. In particular, the 694 studies have focused on how often there appear to be valley-free 695 (e.g. Gao-Rexford [Gao] model) violations, and if they can be 696 explained [Anwar]. One important consideration for explanation of 697 violations is per-prefix routing policies, i.e. routes for prefixes 698 with different peering relationships may be sent over the same link. 699 One encouraging result reported in [Anwar] is that when per-prefix 700 routing policies are taken into consideration in the data analysis, 701 more than 80% of the observed routing decisions fit the valley-free 702 model (see Section 4.3 and SPA-1 data in Figure 2). [Anwar] also 703 observes, "it is well known that this model [the basic Gao-Rexford 704 model and some variations of it] fails to capture many aspects of the 705 interdomain routing system. These aspects include AS relationships 706 that vary based on the geographic region or destination prefix, and 707 traffic engineering via hot-potato routing or load balancing." So 708 there may be potential for explaining the remaining (20% or less) 709 violations of valley-free as well. 711 One major design factor in the methodology described in this document 712 is that the Route-Leak Protection (RLP) encoding is per prefix. So 713 the proposed solution is consistent with ISPs' per-prefix routing 714 policies. Large global and other major ISPs will be the likely early 715 adopters, and they are expected to have expertise in setting policies 716 (including per prefix policies, if applicable), and make proper use 717 of the RLP indications on a per prefix basis. When the large ISPs 718 participate in this solution deployment, it is envisioned that they 719 would form a ring of protection against route leaks, and co- 720 operatively avoid many of the common types of route leaks that are 721 observed. Route leaks may still happen occasionally within the 722 customer cones (if some customer ASes are not participating or not 723 diligently implementing RLP), but said leaks would be much less 724 likely to propagate from one large participating ISP to another. 726 6.4. Comparison with other methods (routing security BCPs) 728 It is reasonable to ask if techniques considered in BCPs such 729 as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be 730 adequate to address route leaks. The prefix filtering 731 recommendations in the BCPs may be complementary but not adequate. 732 The difficulty is in ISPs' ability to construct prefix filters that 733 represent their customer cones (CC) accurately, especially when there 734 are many levels in the hierarchy within the CC. In the RLP-encoding 735 based solution described here, AS operators signal for each route 736 propagated, if it SHOULD NOT be subsequently propagated to a transit 737 provider or peer. 739 AS path based Outbound Route Filter (ORF) described in 740 [I-D.ietf-idr-aspath-orf] is also an interesting complementary 741 technique. It can be used as an automated collaborative messaging 742 system (implemented in BGP) for ISPs to try to develop a complete 743 view of the ASes and AS paths in their CCs. Once an ISP has that 744 view, then AS path filters can be possibly used to detect route 745 leaks. One limitation of this technique is that it cannot duly take 746 into account the fact that routes for prefixes with different peering 747 relationships may be sent over the same link between ASes. Also, the 748 success of AS path based ORF depends on whether ASes at all levels of 749 the hierarchy in a CC participate and provide accurate information 750 (in the ORF messages) about the AS paths they expect to have in their 751 BGP updates. 753 6.5. Per-Hop RLP Field or Single RLP Flag per Update? 755 The route-leak detection and mitigation mechanism described in this 756 document is based on setting RLP Fields on a per-hop basis. There is 757 another possible mechanism based on a single RLP flag per update. 759 Method A - Per-Hop RLP Field: The sender (eBGP router) on each hop in 760 the AS path sets its RLP Field = 1 if sending the update to a 761 customer or lateral peer (see Section 4.3) and Section 4.3.1). No AS 762 (if operating correctly) would rewrite the RLP Field set by any 763 preceding AS. 765 Method B - Single RLP Flag per Update: As it propagates, the update 766 would have at most one RLP flag. Once an eBGP router (in the update 767 path) determines that it is sending an update towards a customer or 768 lateral peer AS, it sets the RLP flag. The flag value equals the AS 769 number of the eBGP router that is setting it. Once the flag is set, 770 subsequent ASes in the path must propagate the flag as is. 772 To compare Methods A and B, consider the example illustrated in 773 Figure 3. Consider a partial deployment scenario in which AS1, AS2, 774 AS3 and AS5 participate in RLP, and AS4 does not. AS1 (2 levels deep 775 in AS3's customer cone) has imperfect RLP operation. Each complying 776 AS's route leak mitigation policy is to prefer an update not marked 777 as route leak (see Section 4.5). If there is no alternative, then a 778 transit-provider may propagate a marked update from a customer. In 779 this example, multi-homed AS4 leaks a route received for prefix Q 780 from transit-provider AS3 to transit-provider AS5. 782 +-----------+ RLP=1 +-----------+ 783 | AS3 |---------->| AS5 | 784 |(Major ISP)| U2 |(Major ISP)| 785 +-----------+ +-----------+ 786 /\ \ /\ U1 787 Route for Q propagated / \RLP=1 / 788 due to lack of /RLP=0 \ / (route leak; 789 alternate route / \/ / bad behavior) 790 +---------+ +-------------+ 791 | AS2 | | AS4 | 792 +---------+ +-------------+ 793 /\ (legacy; does not support RLP) 794 / 795 / 796 /RLP=1 (set incorrectly) 797 / 798 +----------+ 799 | AS1 | 800 +----------+ 801 /\ 802 / 803 / Prefix Q 805 Figure 3: Example for comparison of Method A vs. Method B 807 If Method A is implemented in the network, the two BGP updates for 808 prefix Q received at AS5 are (note that AS4 is not participating in 809 RLP): 811 U1A: Q [AS4 AS3 AS2 AS1] {RLP3(AS3)=1, RLP2(AS2)=0, RLP1(AS1)=1} 812 ..... from AS4 814 U2A: Q [AS3 AS2 AS1] {RLP3(AS3)=1, RLP2(AS2)=0, RLP1(AS1)=1} ..... 815 from AS3 817 Alternatively, if Method B is implemented in the network, the two BGP 818 updates for prefix Q received at AS5 are: 820 U1B: Q [AS4 AS3 AS2 AS1] {RLP(AS1)=1} ..... from AS4 822 U2B: Q [AS3 AS2 AS1] {RLP(AS1)=1} ..... from AS3 824 All received routes for prefix Q at AS5 are marked as route leak in 825 either case (Method A or B). In the case of Method A, AS5 can use 826 additional information gleaned from the RLP fields in the updates to 827 possibly make a better best path selection. For example, AS5 can 828 determine that U1A update received from its customer AS4 exhibits 829 violation of two RLP fields (those set by AS1 and AS3) and one of 830 them was set just two hops away. But U2A update exhibits that only 831 one RLP field was violated and that was set three hops back. Based 832 on this logic, AS5 may prefer U2A over U1A (even though U1A is a 833 customer route). This would be a good decision. However, Method B 834 does not facilitate this kind of more rational decision process. 835 With Method B, both updates U1B and U2B exhibit that they violated 836 only one RLP field (set by AS1 several hops away). AS5 may then 837 prefer U1B over U2B since U1B is from a customer, and that would be 838 bad decision. This illustrates that, due to more information in per- 839 hop RLP Fields, Method A seems to be operationally more beneficial 840 than Method B. 842 Further, for detection and notification of neighbor AS's non- 843 compliance, Method A (per-hop RLP) is better than Method B (single 844 RLP). With Method A, the bad behavior of AS4 would be explicitly 845 evident to AS5 since it violated AS3's (only two hops away) RLP field 846 as well. AS5 would alert AS4 and also AS2 would alert AS1 about lack 847 of compliance (when Method A is used). With Method B, the alerting 848 process may not be as expeditious. 850 7. Security Considerations 852 The proposed Route-Leak Protection (RLP) field requires cryptographic 853 protection in order to prevent malicious route leaks. Since it is 854 proposed that the RLP field be included in the Flags field in the 855 Secure_Path Segment in BGPsec updates, the cryptographic security 856 mechanisms in BGPsec are expected to also apply to the RLP field. 857 The reader is therefore directed to the security considerations 858 provided in [I-D.ietf-sidr-bgpsec-protocol]. 860 8. IANA Considerations 862 IANA is requested to register a new optional, non-transitive BGP Path 863 Attribute, named "Preventive Route Leak Protection (pRLP)" in the BGP 864 Path Attributes registry. The attribute type code is TBD. The 865 reference for this new attribute is this document (i.e. the RFC that 866 replaces this draft). The length of this new attribute is 0. 868 IANA is requested to register a new optional, transitive BGP Path 869 Attribute, named "Route Leak Protection" in the BGP Path Attributes 870 registry. The attribute type code is TBD. The reference for this 871 new attribute is this document (i.e. the RFC that replaces this 872 draft). The length field of this attribute is 2 octets, and the 873 length of the value field of this attribute is variable (see 874 Figure 2) in Section 4.3.1 of this document). 876 9. Acknowledgements 878 The authors wish to thank Jared Mauch, Jeff Haas, Job Snijders, 879 Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy 880 Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes George, Job 881 Snijders, Chris Morrow, Sandy Murphy, Danny McPherson, and Eric 882 Osterweil for comments, suggestions, and critique. The authors are 883 also thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim 884 for their review and comments. 886 10. References 888 10.1. Normative References 890 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 891 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 892 DOI 10.17487/RFC4271, January 2006, 893 . 895 10.2. Informative References 897 [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., 898 and N. Katz-Bassett, "Investigating Interdomain Routing 899 Policies in the Wild", ACM Internet Measurement 900 Conference (IMC), October 2015, 901 . 903 [Cowie2010] 904 Cowie, J., "China's 18 Minute Mystery", Dyn 905 Research/Renesys Blog, November 2010, 906 . 909 [Cowie2013] 910 Cowie, J., "The New Threat: Targeted Internet Traffic 911 Misdirection", Dyn Research/Renesys Blog, November 2013, 912 . 915 [draft-dickson-sidr-route-leak-solns] 916 Dickson, B., "Route Leaks -- Proposed Solutions", IETF 917 Internet Draft (expired), March 2012, 918 . 921 [draft-kunzinger-idrp-ISO10747-01] 922 Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)", 923 IETF Internet Draft (expired), November 1994, 924 . 927 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 928 global coordination", IEEE/ACM Transactions on 929 Networking, December 2001, 930 . 933 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of 934 Interdomain Routing Policies", ACM SIGCOMM Computer 935 Communication Review, January 2014, 936 . 938 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in 939 Internet routing - Analysis based on BGP Community data", 940 IEEE ICC 2012, June 2012. 942 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing 943 Large-scale Routing Anomalies: A Case Study of the China 944 Telecom Incident", PAM 2013, March 2013, 945 . 948 [Huston2012] 949 Huston, G., "Leaking Routes", March 2012, 950 . 952 [Huston2014] 953 Huston, G., "What's so special about 512?", September 954 2014, . 956 [I-D.ietf-idr-aspath-orf] 957 Hares, S. and K. Patel, "AS Path Based Outbound Route 958 Filter for BGP-4", draft-ietf-idr-aspath-orf-13 (work in 959 progress), December 2016. 961 [I-D.ietf-idr-bgp-open-policy] 962 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 963 Sriram, "Route Leak Prevention using Roles in Update and 964 Open messages", draft-ietf-idr-bgp-open-policy-01 (work in 965 progress), July 2017. 967 [I-D.ietf-sidr-bgpsec-protocol] 968 Lepinski, M. and K. Sriram, "BGPsec Protocol 969 Specification", draft-ietf-sidr-bgpsec-protocol-23 (work 970 in progress), April 2017. 972 [Kapela-Pilosov] 973 Pilosov, A. and T. Kapela, "Stealing the Internet: An 974 Internet-Scale Man in the Middle Attack", DEFCON-16 Las 975 Vegas, NV, USA, August 2008, 976 . 979 [Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage", 980 ThousandEyes Blog, June 2015, 981 . 984 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix 985 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, 986 November 2012, . 989 [Labovitz] 990 Labovitz, C., "Additional Discussion of the April China 991 BGP Hijack Incident", Arbor Networks IT Security Blog, 992 November 2010, 993 . 996 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", 997 Project web page, 2012, 998 . 1001 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 1002 kc. claffy, "AS Relationships, Customer Cones, and 1003 Validation", IMC 2013, October 2013, 1004 . 1006 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke 1007 Today", Dyn Research/Renesys Blog, September 2014, 1008 . 1011 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project 1012 web page, 2014, 1013 . 1015 [Mauch-nanog] 1016 Mauch, J., "Detecting Routing Leaks by Counting", 1017 NANOG-41 Albuquerque, NM, USA, October 2007, 1018 . 1021 [Nanog-thread-June2016] 1022 "Intra-AS messaging for route leak prevention", NANOG 1023 Email List - Discussion Thread , June 2016, 1024 . 1027 [NIST-800-54] 1028 Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway 1029 Protocol Security", NIST Special Publication 800-54, July 1030 2007, . 1033 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about 1034 How the Internet Works", CloudFare Blog, November 2012, 1035 . 1038 [proceedings-sixth-ietf] 1039 Gross, P., "Proceedings of the April 22-24, 1987 Internet 1040 Engineering Task Force", April 1987, 1041 . 1043 [RFC1105-obsolete] 1044 Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 1045 (BGP)", IETF RFC (obsolete), June 1989, 1046 . 1048 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1049 Austein, "BGP Prefix Origin Validation", RFC 6811, 1050 DOI 10.17487/RFC6811, January 2013, 1051 . 1053 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 1054 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 1055 February 2015, . 1057 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 1058 and B. Dickson, "Problem Definition and Classification of 1059 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 1060 2016, . 1062 [Snijders] 1063 Snijders, J., "Practical everyday BGP filtering with 1064 AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA, 1065 June 2016, . 1068 [Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. 1069 Robachevsky , "Methods for Detection and Mitigation of BGP 1070 Route Leaks", IETF-95 IDR WG Meeting), April 2016, 1071 . 1074 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August 1075 2014, . 1078 [Toonk2015-A] 1079 Toonk, A., "What caused the Google service interruption", 1080 March 2015, . 1083 [Toonk2015-B] 1084 Toonk, A., "Massive route leak causes Internet slowdown", 1085 June 2015, . 1088 [Wijchers] 1089 Wijchers, B. and B. Overeinder, "Quantitative Analysis of 1090 BGP Route Leaks", RIPE-69, November 2014, 1091 . 1094 [Zmijewski] 1095 Zmijewski, E., "Indonesia Hijacks the World", Dyn 1096 Research/Renesys Blog, April 2014, 1097 . 1100 Authors' Addresses 1102 Kotikalapudi Sriram 1103 US NIST 1105 Email: ksriram@nist.gov 1107 Doug Montgomery 1108 US NIST 1110 Email: dougm@nist.gov 1112 Brian Dickson 1114 Email: brian.peter.dickson@gmail.com 1116 Keyur Patel 1117 Arrcus 1119 Email: keyur@arrcus.com 1121 Andrei Robachevsky 1122 Internet Society 1124 Email: robachevsky@isoc.org