idnits 2.17.1 draft-ietf-idr-route-leak-detection-mitigation-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 230: '...hen this information SHOULD be used to...' RFC 2119 keyword, line 276: '...RLP) field value MUST be set as follow...' RFC 2119 keyword, line 287: '...RLP) field value MUST be set as follow...' RFC 2119 keyword, line 309: '...bsequent AS path SHOULD NOT forward th...' RFC 2119 keyword, line 319: '... An AS MUST NOT rewrite/reset the va...' (6 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 2, 2018) is 2125 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: 'X' is mentioned on line 447, but not defined == Unused Reference: 'RFC7454' is defined on line 537, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-03 -- No information found for draft-sriram-idr-route-leak-solution-design-discussion - is the name correct? Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR and SIDR K. Sriram, Ed. 3 Internet-Draft USA NIST 4 Intended status: Standards Track A. Azimov, Ed. 5 Expires: January 3, 2019 Qrator Labs 6 July 2, 2018 8 Methods for Detection and Mitigation of BGP Route Leaks 9 draft-ietf-idr-route-leak-detection-mitigation-09 11 Abstract 13 Problem definition for route leaks and enumeration of types of route 14 leaks are provided in RFC 7908. This document specifies BGP 15 enhancements that significantly extend its route-leak detection and 16 mitigation capabilities. The solution involves each participating AS 17 setting a route-leak protection (RLP) field in BGP updates. The RLP 18 fields are carried in a new optional transitive attribute, called BGP 19 RLP Attribute. The RLP Attribute helps with detection and mitigation 20 of route leaks at ASes downstream from the leaking AS (in the path of 21 BGP update). This is an inter-AS (multi-hop) solution mechanism. 22 This solution complements the intra-AS (local AS) route-leak 23 avoidance solution that is described in ietf-idr-bgp-open-policy 24 draft. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 3, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Route-Leak Types that the Solution Must Address . . . . . . . 3 62 3. Mechanisms for Detection and Mitigation of Route Leaks . . . 5 63 3.1. Ascertaining Peering Relationship . . . . . . . . . . . . 5 64 3.2. Route-Leak Protection (RLP) Field Encoding by Sending 65 Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. BGP RLP Attribute . . . . . . . . . . . . . . . . . . 8 67 3.2.2. Carrying RLP Field Values in the BGPsec Flags . . . . 9 68 3.3. Recommended Actions at a Receiving Router for Detection 69 and Mitigation of Route Leaks . . . . . . . . . . . . . . 10 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 6.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 RFC 7908 [RFC7908] provides a definition of the route leak problem, 82 and enumerates several types of route leaks. This document first 83 examines which of those route-leak types are detected and mitigated 84 by the existing Origin Validation (OV) [RFC6811] method. OV 85 [RFC6811] and BGPsec path validation [RFC8205] together offer 86 mechanisms to protect against re-originations and hijacks of IP 87 prefixes as well as man-in-the-middle (MITM) AS path modifications. 88 Route leaks [RFC7908] are another type of vulnerability in the global 89 BGP routing system against which OV offers very limited protection. 90 BGPsec path validation provides cryptographic protection for some 91 aspects of BGP update messages, but in its current form BGPsec does 92 not offer any protection against route leaks. 94 For the types of route leaks enumerated in RFC 7908 [RFC7908], where 95 the OV method does not offer a solution, this document specifies BGP 96 enhancements that significantly extend its route-leak detection and 97 mitigation capabilities. The solution involves each participating AS 98 setting a route-leak protection (RLP) field in BGP updates. The RLP 99 fields are carried in a new optional transitive attribute, called BGP 100 RLP Attribute. The RLP Attribute helps with detection and mitigation 101 of route leaks at ASes downstream from the leaking AS (in the path of 102 BGP update). This is an inter-AS (multi-hop) solution mechanism. 103 This solution complements the intra-AS (local AS) route-leak 104 avoidance solution that is described in 105 [I-D.ietf-idr-bgp-open-policy]. 107 The RLP mechanism is backward compatible with BGP routers that are 108 not upgraded to perform RLP. Early adopters would see significant 109 benefits. If a group of big ISPs deploy RLP, then they would be 110 helping each other by blocking route leaks originated within one's 111 customer cone from propagating into a peer's AS or their customer 112 cone. 114 The inter-AS RLP solution is meant to be initially implemented as an 115 enhancement of BGP without requiring BGPsec. However, when BGPsec is 116 deployed in the future, the solution should be incorporated in 117 BGPsec, enabling cryptographic protection for the RLP fields. That 118 is one way of securing the solution against malicious route leaks. 120 2. Route-Leak Types that the Solution Must Address 122 Referring to the enumeration of route leaks discussed in [RFC7908], 123 Table 1 summarizes the route-leak detection capability offered by OV 124 and BGPsec for different types of route leaks. 126 A detailed explanation of the contents of Table 1 is as follows. It 127 is readily observed that route leaks of Types 1, 2, 3, and 4 are not 128 detected by OV or BGPsec in its current form. Clearly, Type 5 route 129 leak involves re-origination or hijacking, and hence can be detected 130 by OV. In the case of Type 5 route leak, there would be no existing 131 ROAs to validate a re-originated prefix or more specific prefix, but 132 instead a covering ROA would normally exist with the legitimate AS, 133 and hence the update will be considered Invalid by OV. 135 +---------------------------------+---------------------------------+ 136 | Type of Route Leak | Current State of Detection | 137 | | Coverage | 138 +---------------------------------+---------------------------------+ 139 | Type 1: Hairpin Turn with Full | Neither OV nor BGPsec (in its | 140 | Prefix | current form) detects Type 1. | 141 | ------------------------------- | ------------------------------- | 142 | Type 2: Lateral ISP-ISP-ISP | Neither OV nor BGPsec (in its | 143 | Leak | current form) detects Type 2. | 144 | ------------------------------- | ------------------------------- | 145 | Type 3: Leak of Transit- | Neither OV nor BGPsec (in its | 146 | Provider Prefixes to Peer | current form) detects Type 3. | 147 | ------------------------------- | ------------------------------- | 148 | Type 4: Leak of Peer Prefixes | Neither OV nor BGPsec (in its | 149 | to Transit Provider | current form) detects Type 4. | 150 | ------------------------------- | ------------------------------- | 151 | Type 5: Prefix Re-Origination | OV detects Type 5. | 152 | with Data Path to Legitimate | | 153 | Origin | | 154 | ------------------------------- | ------------------------------- | 155 | Type 6: Accidental Leak of | For internal prefixes never | 156 | Internal Prefixes and More | meant to be routed on the | 157 | Specific Prefixes | Internet, OV helps detect their | 158 | | leak; they might either have no | 159 | | covering ROA or have an AS0-ROA | 160 | | to always filter them. In the | 161 | | case of accidental leak of more | 162 | | specific prefixes, OV may offer | 163 | | some detection due to ROA | 164 | | maxLength. | 165 +---------------------------------+---------------------------------+ 167 Table 1: Examination of Route-Leak Detection Capability of Origin 168 Validation and Current BGPsec Path Validation 170 In the case of Type 6 leaks involving internal prefixes that are not 171 meant to be routed in the Internet, they are likely to be detected by 172 OV. That is because such prefixes might either have no covering ROA 173 or have an AS0-ROA to always filter them. In the case of Type 6 174 leaks that are due to accidental leak of more specific prefixes, they 175 may be detected due to violation of ROA maxLength. BGPsec (i.e., 176 path validation) in its current form does not detect Type 6. 177 However, route leaks of Type 6 are least problematic due to the 178 following reasons. In the case of leak of more specific prefixes, 179 the offending AS is itself the legitimate destination of the leaked 180 more-specific prefixes. Hence, in most cases of this type, the data 181 traffic is not misrouted. Also, leaked announcements of Type 6 are 182 short-lived and typically withdrawn quickly following the 183 announcements. Further, the MaxPrefix limit may kick-in in some 184 receiving routers and that helps limit the propagation of sometimes 185 large number of leaked routes of Type 6. 187 Realistically, BGPsec may take a much longer time being deployed than 188 OV. Hence, solution proposals for route leaks should consider both 189 scenarios: (A) OV only (without BGPsec) and (B) OV plus BGPsec. 190 Assuming an initial scenario A, and based on the above discussion and 191 Table 1, it is evident that the solution method should focus 192 primarily on route leaks of Types 1, 2, 3, and 4. 194 3. Mechanisms for Detection and Mitigation of Route Leaks 196 There are two considerations for route leaks: (1) Prevention of route 197 leaks from a local AS [I-D.ietf-idr-bgp-open-policy], and (2) 198 Detection and mitigation of route leaks in ASes that are downstream 199 from the leaking AS (in the path of BGP update). This document 200 specifies the latter. 202 3.1. Ascertaining Peering Relationship 204 There are four possible peering relationships (i.e., roles) an AS can 205 have with a neighbor AS: (1) Provider: transit-provider for all 206 prefixes exchanged, (2) Customer: customer for all prefixes 207 exchanged, (3) Lateral Peer: lateral peer (i.e., non-transit) for all 208 prefixes exchanged, and (4) Complex: different relationships for 209 different sets of prefixes [Luckie]. For the complex case, the 210 peering role types provider, customer, or lateral peer apply for 211 different non-overlapping sets of prefixes. 213 Operators rely on some form of out-of-band (OOB) (i.e., external to 214 BGP) communication to exchange information about their peering 215 relationship, AS number, interface IP address, etc. If the 216 relationship is complex, the OOB communication also includes the sets 217 of prefixes for which they have different roles. 218 [I-D.ietf-idr-bgp-open-policy] introduces a method of re-confirming 219 the BGP Role during BGP OPEN messaging (except when the role is 220 complex). It defines a new BGP Role capability, which helps in re- 221 confirming the relationship when it is provider, customer, or lateral 222 peer. BGP Role does not replace the OOB communication since it 223 relies on the OOB communication to set the role type in the BGP OPEN 224 message. However, BGP Role provides a means to double check, and if 225 there is a contradiction detected via the BGP Role messages, then a 226 Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy]. 228 When the BGP relationship information has been correctly exchanged 229 (i.e., free of contradictions) including the sets of prefixes with 230 different roles (if complex), then this information SHOULD be used to 231 automatically set the role per-prefix with each peer. For example, 232 if the local AS's role is Provider with a neighbor AS, then the per- 233 prefix role is set to 'Provider' for all prefixes sent to the 234 neighbor, and set to 'Customer' for all prefixes received from the 235 neighbor. 237 Once the per-prefix roles are set, this information is used in the 238 RLP solution mechanism that is described in Section 3.2 and 239 Section 3.3. 241 3.2. Route-Leak Protection (RLP) Field Encoding by Sending Router 243 The key principle is that, in the event of a route leak, a receiving 244 router in a transit-provider AS (e.g., referring to Figure 1, ISP2 245 (AS2) router) should be able to detect from the update message that 246 its customer AS (e.g., AS3 in Figure 1) should not have forwarded the 247 update (towards the transit-provider AS). This means that at least 248 one of the ASes in the AS path of the update signaled that it sent 249 the update to its customer or lateral peer, but forbade any 250 subsequent 'Up' (customer to provider) or 'Lateral' (peer to peer) 251 forwarding. This signaling is achieved by a Route-Leak Protection 252 (RLP) field as described below. 254 /\ /\ 255 \ route-leak(P)/ 256 \ propagated / 257 \ / 258 +------------+ peer +------------+ 259 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> 260 / ------------+ prefix(P) +------------+ route-leak(P) 261 | prefix | \ update /\ \ propagated 262 \ (P) / \ / \ 263 ------- prefix(P) \ / \ 264 update \ / \ 265 \ /route-leak(P) \/ 266 \/ / 267 +---------------+ 268 | customer(AS3) | 269 +---------------+ 271 Figure 1: Illustration of the basic notion of a route leak. 273 * Design A: 275 For route-leak detection and mitigation, the Route Leak Protection 276 (RLP) field value MUST be set as follows: 278 o Insert the public registered local AS number and RLP = 0 when BGP 279 UPDATE is forwarded to a transit provider, 281 o Insert the public registered local AS number and RLP = 1 when BGP 282 UPDATE is forwarded to a customer or lateral peer. 284 * Design B: 286 For route-leak detection and mitigation, the Route Leak Protection 287 (RLP) field value MUST be set as follows: 289 o Do not insert anything when BGP UPDATE is forwarded to a transit 290 provider, 292 o Insert the public registered local AS number when BGP UPDATE is 293 forwarded to a customer or lateral peer. 295 Note: Design A requires all participating ASes in the path to 296 indicate the direction in which the BGP UPDATE is sent. On the other 297 hand, Design B requires participating ASes to insert their AS number 298 only when the BGP UPDATE is sent to a customer or lateral peer. 299 After discussion in the WG, one of the designs will be finalized. It 300 will be discussed if the extra information provided in Design A adds 301 value for route leak detection and mitigation. 303 Note: In the rest of this document, by "RLP is set" it is meant that 304 RLP = 1 for one or more ASes in the AS path (in Design A), or, that 305 the RLP Attribute (with one or more AS numbers in it) is present (in 306 Design B). Further, in the context of either design, "RLP includes 307 AS X" means that "RLP is set" by AS X which is in the path. The 308 intent of setting RLP is that the neighbor AS or any receiving AS 309 along the subsequent AS path SHOULD NOT forward the UPDATE 'Up' 310 towards its transit-provider AS or laterally towards its peer AS. 312 The RLP fields are set on a per prefix basis. This is because some 313 peering relations between neighbors can be complex (see Section 3.1). 315 Either Design A or B (described above) works for detection and 316 mitigation of route leaks of Types 1, 2, 3, and 4 which are the focus 317 here (see Section 3.3). 319 An AS MUST NOT rewrite/reset the values set by any preceding ASes in 320 their respective RLP fields. 322 The RLP encoding MUST be carried in BGP-4 [RFC4271] updates in a new 323 BGP optional transitive attribute (see Section 3.2.1). In BGPsec, it 324 must be carried in the Flags field (see Section 3.2.2). 326 In partial deployment, there may be eBGP routers in the AS path that 327 are not upgraded and hence do not participate in RLP. However, the 328 RLP mechanism is backward compatible. Participating ASes can detect 329 and mitigate route leaks while ASes not upgraded might remain 330 vulnerable. If big ISPs deploy RLP, then they would be helping each 331 other by not allowing route leaks originated within one's customer 332 cone to propagate into another's AS or their customer cone. This 333 accords significant benefit to early adopters. 335 3.2.1. BGP RLP Attribute 337 The BGP RLP Attribute is a new BGP optional transitive attribute. 338 The attribute type code for the RLP Attribute is to be assigned by 339 IANA. The length field of this attribute is 2 octets. 341 * RLP Attribute for Design A: 343 The value field of the RLP Attribute is defined as a set of one or 344 more pairs of ASN (4 octets) and RLP (one octet) fields as described 345 below (Figure 2). 347 +-----------------------+ -\ 348 | ASN: N | | 349 +-----------------------+ > (Most recently added) 350 | RLP: N | | 351 +-----------------------+ -/ 352 ........... 353 +-----------------------+ -\ 354 | ASN: 1 | | 355 +-----------------------+ > (Least recently added) 356 | RLP: 1 | | 357 +-----------------------+ -/ 359 Figure 2: BGP RLP Attribute format. 361 The RLP Attribute value is a sequence of these two components (see 362 Figure 2): 364 ASN: Four octets encoding the public registered AS number of a BGP 365 speaker. 367 RLP Field: One octet encoding the RLP Field bits. The value of the 368 RLP Field octet can be 0 (decimal) or 1 (decimal) as described above 369 in Section 3.2.1. Its usage will be further discussed in subsequent 370 sections. 372 If all ASes in the AS_PATH of a route are upgraded to participate in 373 RLP, then the ASNs in the RLP TLV in Figure 2 will correspond one-to- 374 one with sequence of ASes in the AS_PATH (excluding prepends). If 375 some ASes do not participate, then one or more {ASN, RLP} tuples may 376 be missing in the RLP Attribute relative to the AS_PATH. 378 * RLP Attribute for Design B: 380 The value field of the RLP Attribute is defined as a sequence of one 381 or more ASN (4 octets) fields as described below (Figure 3). 383 +-----------------------+ 384 | ASN: N | (Most recently added) 385 +-----------------------+ 386 | ASN: N-1 | 387 +-----------------------+ 388 ........... 389 +-----------------------+ 390 | ASN: 2 | 391 +-----------------------+ 392 | ASN: 1 | (Least recently added) 393 +-----------------------+ 395 Figure 3: BGP RLP Attribute format. 397 Thus, the RLP Attribute value is a sequence public registered AS 398 numbers (see Figure 3). The ASNs of only the participating 399 (upgraded) ASes that sent the BGP UPDATE to a customer or lateral 400 peer appear in the RLP Attribute. 402 3.2.2. Carrying RLP Field Values in the BGPsec Flags 404 In BGPsec-enabled routers that are also performing RLP, the RLP 405 encoding MUST be accommodated in the existing Flags field in BGPsec 406 updates. The Flags field is part of the Secure_Path Segment in 407 BGPsec updates [RFC8205]. One Flags field (one octet in size) is 408 available for each AS hop, and currently only the first bit is used 409 in BGPsec. So, there are 7 bits that are currently unused in the 410 Flags field. One of these bits can be designated for the RLP field 411 value (see Section 3.2.1). This bit is set to 0 when the RLP Field 412 value is 0 and set to 1 when the RLP Field value is 1. Since the 413 BGPsec protocol specification requires a sending AS to include the 414 Flags field in the data that are signed over, the RLP field for each 415 hop (since it would be part of the Flags field as described) will be 416 protected under the sending AS's signature. 418 3.3. Recommended Actions at a Receiving Router for Detection and 419 Mitigation of Route Leaks 421 Route Leak Detection: 423 When a customer route has at least one or more RLP fields set (to 424 indicate 'do not propagate to provider or peer') by any AS(es) 425 preceding the customer AS, then the route MUST be marked as route 426 leak. The same applies in the case of a peer route also. 428 Route Leak Mitigation: 430 For the most part, route leak mitigation policy can be set locally by 431 a network operator. However, the following rules MUST be included in 432 any route leak mitigation policy. These rules ensure stable route 433 convergence and avoid the possibility of persistent route 434 oscillations (see Section 3.1 in the route leak solution discussion 435 document [RLP-Discussion] for an explanation). 437 o Rule 1: If ISP A receives a route r1 from customer AS C and 438 another route r2 from provider (or peer) AS B (for the same 439 prefix), and both routes r1 and r2 contain AS C and AS X (any X 440 not equal to C) in the path and also contain [X] in their RLP 441 Attributes, then prioritize the customer (AS C) route over the 442 provider (or peer) route. 444 o Rule 2: If ISP A receives a route r1 from peer AS C and another 445 route r2 from provider AS B (for the same prefix), and both routes 446 r1 and r2 contain AS C and AS X (any X not equal to C) in the path 447 and also contain [X] in their RLP Attributes, then prioritize the 448 peer (AS C) route over the provider (AS B) route. 450 Including the rules stated above, the RECOMMENDED route leak 451 mitigation policy is as follows: 453 1. Given a choice between a customer route versus a provider (or 454 peer) route, 456 * if no route leak is detected in the customer route, then 457 prioritize the customer over the provider (or peer); 459 * else (i.e., when route leak is detected in the customer route) 460 and the conditions of Rule 1 apply, then too prioritize the 461 customer over the provider (or peer); 463 * else (i.e., when route leak is detected in the customer route 464 and the conditions of Rule 1 DO NOT apply), then prioritize 465 the provider (or peer) over the customer. 467 2. Given a choice between a peer route versus a provider route, 469 * if no route leak is detected in the peer route, then 470 prioritize the peer over the provider; 472 * else (i.e., when route leak is detected in the peer route) and 473 the conditions of Rule 2 apply, then too prioritize the peer 474 over the provider; 476 * else (i.e., when route leak is detected in the peer route and 477 the conditions of Rule 2 DO NOT apply), then prioritize the 478 provider over the peer. 480 In the case of choosing between a peer route and a provider route, 481 network operators MAY apply a policy (different from the above) that 482 they deem appropriate in their operating environment. 484 4. Security Considerations 486 The Route-Leak Protection (RLP) field requires cryptographic 487 protection to prevent malicious route leaks. In the future, in 488 conjunction with BGPsec deployment, the RLP field will be included in 489 the Flags field in the Secure_Path Segment in BGPsec updates. So, 490 the cryptographic security mechanisms in BGPsec will also apply to 491 the RLP field. The reader is therefore directed to the security 492 considerations provided in [RFC8205]. 494 5. IANA Considerations 496 IANA is requested to register a new optional, transitive attribute, 497 named "Route Leak Protection (RLP) Attribute" in the BGP Path 498 Attributes registry. The attribute type code is TBD. The reference 499 for this new attribute is this document (i.e., the RFC that replaces 500 this draft). The length field of this attribute is 2 octets, and the 501 length of the value field of this attribute is variable (see 502 Figure 2) in Section 3.2.1 of this document). 504 6. References 506 6.1. Normative References 508 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 509 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 510 DOI 10.17487/RFC4271, January 2006, 511 . 513 6.2. Informative References 515 [draft-dickson-sidr-route-leak-solns] 516 Dickson, B., "Route Leaks -- Proposed Solutions", IETF 517 Internet Draft (expired), March 2012, 518 . 521 [I-D.ietf-idr-bgp-open-policy] 522 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 523 Sriram, "Route Leak Prevention using Roles in Update and 524 Open messages", draft-ietf-idr-bgp-open-policy-03 (work in 525 progress), June 2018. 527 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 528 kc. claffy, "AS Relationships, Customer Cones, and 529 Validation", IMC 2013, October 2013, 530 . 532 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 533 Austein, "BGP Prefix Origin Validation", RFC 6811, 534 DOI 10.17487/RFC6811, January 2013, 535 . 537 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 538 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 539 February 2015, . 541 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 542 and B. Dickson, "Problem Definition and Classification of 543 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 544 2016, . 546 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 547 Specification", RFC 8205, DOI 10.17487/RFC8205, September 548 2017, . 550 [RLP-Discussion] 551 Sriram (Ed.), K., "Design Discussion of Route Leaks 552 Solution Methods", Work in Progress, draft-sriram-idr- 553 route-leak-solution-design-discussion-00, July 2018. 555 Acknowledgements 557 The authors wish to thank Jared Mauch, Jeff Haas, Job Snijders, 558 Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy 559 Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes George, Job 560 Snijders, Chris Morrow, Sandy Murphy, Danny McPherson, and Eric 561 Osterweil for comments, suggestions, and critique. The authors are 562 thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim for 563 their review and comments. 565 Contributors 567 The following people made significant contributions to this document 568 and should be considered co-authors: 570 Brian Dickson 571 Independent 572 Email: brian.peter.dickson@gmail.com 574 Doug Montgomery 575 USA National Institute of Standards and Technology 576 Email: dougm@nist.gov 578 Keyur Patel 579 Arrcus 580 Email: keyur@arrcus.com 582 Andrei Robachevsky 583 Internet Society 584 Email: robachevsky@isoc.org 586 Eugene Bogomazov 587 Qrator Labs 588 Email: eb@qrator.net 590 Randy Bush 591 Internet Initiative Japan 592 Email: randy@psg.com 594 Authors' Addresses 596 Kotikalapudi Sriram (editor) 597 USA National Institute of Standards and Technology 598 100 Bureau Drive 599 Gaithersburg, MD 20899 600 United States of America 602 Email: ksriram@nist.gov 603 Alexander Azimov (editor) 604 Qrator Labs 605 1-Y Magistral'nyy Tupik 606 Moskva, XYZ 123007 607 Russia 609 Email: aa@qrator.net