idnits 2.17.1 draft-sriram-idr-route-leak-solution-discussion-00.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 482: '...all AS operators SHOULD implement the ...' RFC 2119 keyword, line 513: '...the ISP's router SHOULD prefer an alte...' 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 2115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 198, but not defined == Unused Reference: 'RFC4271' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'Gill' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'Luckie' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC7908' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC8205' is defined on line 655, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-03 == Outdated reference: A later version (-11) exists of draft-ietf-idr-route-leak-detection-mitigation-08 -- Obsolete informational reference (is this intentional?): RFC 1105 (Obsoleted by RFC 1163) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group K. Sriram, Ed. 3 Internet-Draft USA NIST 4 Intended status: Informational July 2, 2018 5 Expires: January 3, 2019 7 Design Discussion of Route Leaks Solution Methods 8 draft-sriram-idr-route-leak-solution-discussion-00 10 Abstract 12 This document captures the design rationale of the route leaks 13 solution document [draft-ietf-idr-route-leak-detection-mitigation]. 14 The designers needed to balance many competing factors, and this 15 document provides insights into the design questions and their 16 resolution. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 2 54 3. Design Rationale and Discussion . . . . . . . . . . . . . . . 3 55 3.1. Explanation of Rules 1 and 2 in the solution document . . 3 56 3.2. Is route-leak solution without cryptographic protection 57 an attack vector? . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Combining results of route-leak detection, OV and BGPsec 59 validation for path selection decision . . . . . . . . . 6 60 3.4. Are there cases when valley-free violations can be 61 considered legitimate? . . . . . . . . . . . . . . . . . 6 62 3.5. Comparison with other methods (routing security BCPs) . . 7 63 3.6. Per-Hop RLP Field or Single RLP Flag per Update? . . . . 8 64 3.7. Prevention of Route Leaks at Local AS: Intra-AS Messaging 10 65 3.7.1. Non-Transitive BGP Community for Intra-AS Messaging . 10 66 3.8. Stopgap Solution when Only Origin Validation is Deployed 11 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 6.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 This document captures the design rationale of the route leaks 79 solution document [I-D.ietf-idr-route-leak-detection-mitigation]. 80 The designers needed to balance many competing factors, and this 81 document provides insights into the design questions and their 82 resolution. 84 2. Related Prior Work 86 The solution described in 87 [I-D.ietf-idr-route-leak-detection-mitigation] is based on setting an 88 attribute in BGP route announcement to manage the transmission/ 89 receipt of the announcement based on the type of neighbor (e.g., 90 customer, transit provider, etc.). Documented prior work related to 91 this basic idea and mechanism dates back to at least the 1980's. 92 Some examples of prior work are: (1) Information flow rules described 93 in [proceedings-sixth-ietf] (see pp. 195-196); (2) Link Type 94 described in [RFC1105-obsolete] (see pp. 4-5); (3) Hierarchical 95 Recording described in [draft-kunzinger-idrp-ISO10747-01] (see 96 Section 6.3.1.12). The problem of route leaks and possible solution 97 mechanisms based on encoding peering-link type information, e.g., P2C 98 (i.e., Transit-Provider to Customer), C2P (i.e., Customer to Transit- 99 Provider), p2p (i.e., peer to peer) etc., in BGPsec updates and 100 protecting the same under BGPsec path signatures have been discussed 101 in IETF SIDR WG at least since 2011. 102 [draft-dickson-sidr-route-leak-solns] attempted to describe these 103 mechanisms in a BGPsec context. The draft expired in 2012. 104 [draft-dickson-sidr-route-leak-solns] defined neighbor relationships 105 on a per link basis, but in 106 [I-D.ietf-idr-route-leak-detection-mitigation] the relationship is 107 encoded per prefix, as routes for prefixes with different peering 108 relationships may be sent over the same link. Also 109 [draft-dickson-sidr-route-leak-solns] proposed a second signature 110 block for the link type encoding, separate from the path signature 111 block in BGPsec. By contrast, in 112 [I-D.ietf-idr-route-leak-detection-mitigation], when BGPsec-based 113 solution is considered, cryptographic protection is provided for 114 Route-Leak Protection (RLP) encoding using the same signature block 115 as that for path signatures (see Section 3.2.2 in 116 [I-D.ietf-idr-route-leak-detection-mitigation]). 118 3. Design Rationale and Discussion 120 This section provides design justifications for the solution 121 specified in [I-D.ietf-idr-route-leak-detection-mitigation], and also 122 answers some questions that are anticipated or have been raised in 123 the IETF IDR and SIDR working group meetings. 125 3.1. Explanation of Rules 1 and 2 in the solution document 127 In Section 3.3 in [I-D.ietf-idr-route-leak-detection-mitigation], 128 Rules 1 and 2 were stated and the route leak mitigation policy was 129 based on these rules to preserve the property of stable route 130 convergence (i.e., avoid possibility of persistent route 131 oscillations). Rule 1 is stated as follows: 133 o Rule 1: If ISP A receives a route r1 from customer AS C and 134 another route r2 from provider (or peer) AS B (for the same 135 prefix), and both routes r1 and r2 contain AS C and AS X (any X 136 not equal to C) in the path and contain [X] in their RLP 137 Attributes, then prioritize the customer (AS C) route over the 138 provider (or peer) route. 140 The rationale for Rule 1 can be developed as follows. 142 Preference condition for route stability: Prefer customer routes over 143 peer or provider routes (see pp. 25-27 in [Gao-Rexford]). 145 Topology condition for route stability: No cycle of customer-provider 146 relationships (see pp. 25-27 in [Gao-Rexford]). 148 Route-Leak Detection Theorem: Let it be given that ISP A receives a 149 route r1 from customer AS C and another route r2 from provider AS B 150 (for the same prefix), and each of the routes r1 and r2 contains AS C 151 and AS X in its AS path and contains [X] in its RLP Attribute. Then, 152 clearly r1 is in violation of [X]. It follows that r2 is also 153 necessarily in violation of [X]. 155 Proof: Let us suppose that r2 is not in violation of [X]. That 156 implies that r2's path from C to B to A included only P2C links. 157 That would mean that there is a cycle of customer-provider 158 relationships involving the ASes in the AS path in r2. However, any 159 such cycle is ruled out in practice by the topology condition for 160 route stability as stated above. QED. 162 Corollary 1: The route leak detection theorem holds also when 163 "provider AS B" in the theorem is replaced by "peer AS B". (Here 164 peer means a lateral peer.) 166 Proof: Since r2 contains [X] in the RLP Attribute set by an AS prior 167 to peer AS B, it follows that r2 is in violation of [X]. QED. 169 It can be observed that Rule 1 follows from the combination of the 170 Theorem, Corollary 1 and the preference condition for route stability 171 (stated above). 173 In Section 3.3 in [I-D.ietf-idr-route-leak-detection-mitigation], 174 Rule 2 is stated as follows: 176 o Rule 2: If ISP A receives a route r1 from peer AS C and another 177 route r2 from provider AS B (for the same prefix), and both routes 178 r1 and r2 contain AS C and AS X (any X not equal to C) in the path 179 and contain [X] in their RLP Attributes, then prioritize the peer 180 (AS C) route over the provider (AS B) route. 182 The rationale for Rule 2 can be developed as follows. 184 Corollary 2: The route leak detection theorem holds also when 185 "customer AS C" in the theorem is replaced by "peer AS C". 187 Proof for Corollary 2: Let us suppose that r2 is not in violation of 188 [X]. That implies that r2's path from C to B to A included only P2C 189 links. This results in a topology in which A's lateral peer B is 190 also A's transit provider's transit provider. This gives rise to 191 possibility of looping of routes since A can send routes to its 192 transit B, B can forward the routes to its transit C, and C can 193 forward the routes to its peer A. But such looping is forbidden by 194 the topology condition stated above. 196 It can be observed that Rule 2 follows from Corollary 2. In essence, 197 if the provider route (r2) is a detoured (longer) version of the 198 lateral peer route (r1), and violates the same RLP [X] as does the 199 peer route, then prefer the shorter route (r2) via the peer. 201 Rules 1 and 2 are 203 3.2. Is route-leak solution without cryptographic protection an attack 204 vector? 206 It has been asked if a route-leak solution without BGPsec, i.e., when 207 RLP Fields are not protected, can turn into a new attack vector. The 208 answer seems to be: not really! Even the NLRI and AS_PATH in BGP 209 updates are attack vectors, and RPKI/OV/BGPsec seek to fix that. 210 Consider the following. Say, if 99% of route leaks are accidental 211 and 1% are malicious, and if route-leak solution without BGPsec 212 eliminates the 99%, then perhaps it is worth it (step in the right 213 direction). When BGPsec comes into deployment, the route-leak 214 protection (RLP) bits can be mapped into BGPsec (using the Flags 215 field) and then necessary security will be in place as well (within 216 each BGPsec island as and when they emerge). 218 Further, let us consider the worst-case damage that can be caused by 219 maliciously manipulating the RLP Field values in an implementation 220 without cryptographic protection (i.e., sans BGPsec). Manipulation 221 of the RLP bits can result in one of two types of attacks: (a) 222 Upgrade attack and (b) Downgrade attack. Descriptions and 223 discussions about these attacks follow. In what follows, P2C stands 224 for transit provider to customer (Down); C2P stands for customer to 225 transit provider (Up), and p2p stands for peer to peer (lateral or 226 non-transit relationship). 228 (a) Upgrade attack: An AS that wants to intentionally leak a route 229 would alter the RLP encodings for the preceding hops from 1 (i.e., 230 'Do not Propagate Up or Lateral') to 0 (default) wherever applicable. 231 This poses no problem for a route that keeps propagating in the 232 'Down' (P2C) direction. However, for a route that propagates 'Up' 233 (C2P) or 'Lateral' (p2p), the worst that can happen is that a route 234 leak goes undetected. That is, a receiving router would not be able 235 to detect the leak for the route in question by the RLP mechanism 236 described here. However, the receiving router may still detect and 237 mitigate it in some cases by applying other means such as prefix 238 filters [RFC7454] [NIST-800-54]. If some malicious leaks go 239 undetected (when RLP is deployed without BGPsec) that is possibly a 240 small price to pay for the ability to detect the bulk of route leaks 241 that are accidental. 243 (b) Downgrade attack: RLP encoding is set to 1 (i.e., 'Do not 244 Propagate Up or Lateral') when it should be set to 0 (default). This 245 would result in a route being mis-detected and marked as a route 246 leak. By default, RLP encoding is set to 0, and that helps reduce 247 errors of this kind (i.e., accidental downgrade incidents). Every AS 248 or ISP wants reachability for prefixes it originates and for its 249 customer prefixes. So, an AS or ISP is not likely to change an RLP 250 value 0 to 1 intentionally. If a route leak is detected (due to 251 intentional or accidental downgrade) by a receiving router, it would 252 prefer an alternate 'clean' route from a transit provider or peer 253 over a 'marked' route from a customer. It may end up with a 254 suboptimal path. In order to have reachability, the receiving router 255 would accept a 'marked' route if there is no alternative that is 256 'clean'. So, RLP downgrade attacks (intentional or accidental) would 257 be quite rare, and the consequences do not appear to be grave. 259 3.3. Combining results of route-leak detection, OV and BGPsec 260 validation for path selection decision 262 Combining the results of route-leak detection, OV, and BGPsec 263 validation for path selection decision is up to local policy in a 264 receiving router. As an example, a router may always give precedence 265 to outcomes of OV and BGPsec validation over that of route-leak 266 detection. That is, if an update fails OV or BGPsec validation, then 267 the update is not considered a candidate for path selection. 268 Instead, an alternate update is chosen that passed OV and BGPsec 269 validation and additionally was not marked as route leak. 271 If only OV is deployed (and not BGPsec), then there are six possible 272 combinations between OV and route-leak detection outcomes. Because 273 there are three possible outcomes for OV (NotFound, Valid, and 274 Invalid) and two possible outcomes for route-leak detection (marked 275 as leak and not marked). If OV and BGPsec are both deployed, then 276 there are twelve possible combinations between OV, BGPsec validation, 277 and route-leak detection outcomes. As stated earlier, since BGPsec 278 protects the RLP encoding, there would be added certainty in route- 279 leak detection outcome if an update is BGPsec valid (see 280 Section 3.2). 282 3.4. Are there cases when valley-free violations can be considered 283 legitimate? 285 There are studies in the literature [Anwar] [Giotsas] [Wijchers] 286 observing and analyzing the behavior of routes announced in BGP 287 updates using data gathered from the Internet. The studies have 288 focused on how often there appear to be valley-free (e.g., Gao- 289 Rexford [Gao] model) violations, and if they can be explained 290 [Anwar]. One important consideration for explanation of the 291 violations is per-prefix routing policies, i.e., routes for prefixes 292 with different peering relationships may be sent over the same link. 293 One encouraging result reported in [Anwar] is that when per-prefix 294 routing policies are taken into consideration in the data analysis, 295 more than 80% of the observed routing decisions fit the valley-free 296 model (see Section 4.3 and SPA-1 data in Figure 2). [Anwar] also 297 observes, "it is well known that this model [the basic Gao-Rexford 298 model and some variations of it] fails to capture many aspects of the 299 interdomain routing system. These aspects include AS relationships 300 that vary based on the geographic region or destination prefix, and 301 traffic engineering via hot-potato routing or load balancing." So, 302 there may be potential for explaining the remaining (20% or less) 303 violations of valley-free as well. 305 One major design factor is that the Route-Leak Protection (RLP) 306 encoding is per prefix. Hence, the solution is consistent with ISPs' 307 per-prefix routing policies. Large global and other major ISPs will 308 be the likely early adopters, and they are expected to have expertise 309 in setting policies (including per prefix policies, if applicable), 310 and make proper use of the RLP indications on a per prefix basis. 311 When the large ISPs participate in this solution deployment, it is 312 envisioned that they would form a ring of protection against route 313 leaks, and co-operatively avoid many of the common types of route 314 leaks that are observed. Route leaks may still happen occasionally 315 within the customer cones (if some customer ASes are not 316 participating or not diligently implementing RLP), but such leaks are 317 unlikely to propagate from one large participating ISP to another. 319 3.5. Comparison with other methods (routing security BCPs) 321 It is reasonable to ask if techniques considered in BCPs such 322 as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be 323 adequate to address route leaks. The prefix filtering 324 recommendations in the BCPs may be complementary but not adequate. 325 The difficulty is in ISPs' ability to construct prefix filters that 326 represent their customer cones (CC) accurately, especially when there 327 are many levels in the hierarchy within the CC. In the RLP-encoding 328 based solution described here, each AS sets RLP for each route 329 propagated and thus signals if it must not be subsequently propagated 330 to a transit provider or peer. 332 AS path based Outbound Route Filter (ORF) described in 333 [I-D.ietf-idr-aspath-orf] is also an interesting complementary 334 technique. It can be used as an automated collaborative messaging 335 system (implemented in BGP) for ISPs to try to develop a complete 336 view of the ASes and AS paths in their CCs. Once an ISP has that 337 view, then AS path filters can be possibly used to detect route 338 leaks. One limitation of this technique is that it cannot duly take 339 into account the fact that routes for prefixes with different peering 340 relationships may be sent over the same link between ASes. Also, the 341 success of AS path based ORF depends on whether ASes at all levels of 342 the hierarchy in a CC participate and provide accurate information 343 (in the ORF messages) about the AS paths they expect to have in their 344 BGP updates. 346 3.6. Per-Hop RLP Field or Single RLP Flag per Update? 348 The route-leak detection and mitigation mechanism described in 349 [I-D.ietf-idr-route-leak-detection-mitigation] is based on setting 350 RLP Fields on a per-hop basis. There is another possible mechanism 351 based on a single RLP flag per update. 353 Method A - Per-Hop RLP Field: The sender (eBGP router) on each hop in 354 the AS path sets its RLP Field = 1 if sending the update to a 355 customer or lateral peer (see Section 3.2 in 356 [I-D.ietf-idr-route-leak-detection-mitigation]). No AS (if operating 357 correctly) would rewrite the RLP Field set by any preceding AS. 359 Method Z - Single RLP Flag per Update: As it propagates, the update 360 would have at most one RLP flag. Once an eBGP router (in the update 361 path) determines that it is sending an update towards a customer or 362 lateral peer AS, it sets the RLP flag. The flag value equals the AS 363 number of the eBGP router that is setting it. Once the flag is set, 364 subsequent ASes in the path must propagate the flag as is. 366 To compare Methods A and Z, consider the example illustrated in 367 Figure 1. Consider a partial deployment scenario in which AS1, AS2, 368 AS3 and AS5 participate in RLP, and AS4 does not. AS1 (2 levels deep 369 in AS3's customer cone) has imperfect RLP operation. Each complying 370 AS's route leak mitigation policy is to prefer an update not marked 371 as route leak (see Section 3.3 in 372 [I-D.ietf-idr-route-leak-detection-mitigation]). If there is no 373 alternative, then a transit-provider may accept and propagate a 374 marked update from a customer to avoid unreachability. In this 375 example, multi-homed AS4 leaks a route received for prefix Q from 376 transit-provider AS3 to transit-provider AS5. 378 +-----------+ RLP=1 +-----------+ 379 | AS3 |---------->| AS5 | 380 |(Major ISP)| U2 |(Major ISP)| 381 +-----------+ +-----------+ 382 /\ \ /\ U1 383 Route for Q propagated / \RLP=1 / 384 due to lack of /RLP=0 \ / (route leak; 385 alternate route / \/ / bad behavior) 386 +---------+ +-------------+ 387 | AS2 | | AS4 | 388 +---------+ +-------------+ 389 /\ (legacy; does not support RLP) 390 / 391 / 392 /RLP=1 (set incorrectly) 393 / 394 +----------+ 395 | AS1 | 396 +----------+ 397 /\ 398 / 399 / Prefix Q 401 Figure 1: Example for comparison of Method A vs. Method Z 403 If Method A is implemented in the network, the two BGP updates for 404 prefix Q received at AS5 are (note that AS4 is not participating in 405 RLP): 407 U1A: Q [AS4 AS3 AS2 AS1] {RLP3(AS3)=1, RLP2(AS2)=0, RLP1(AS1)=1} 408 ..... from AS4 410 U2A: Q [AS3 AS2 AS1] {RLP3(AS3)=1, RLP2(AS2)=0, RLP1(AS1)=1} ..... 411 from AS3 413 Alternatively, if Method Z is implemented in the network, the two BGP 414 updates for prefix Q received at AS5 are: 416 U1B: Q [AS4 AS3 AS2 AS1] {RLP(AS1)=1} ..... from AS4 418 U2B: Q [AS3 AS2 AS1] {RLP(AS1)=1} ..... from AS3 420 All received routes for prefix Q at AS5 are marked as route leak in 421 either case (Method A or Z). In the case of Method A, AS5 can use 422 additional information gleaned from the RLP fields in the updates to 423 possibly make a better best path selection. For example, AS5 can 424 determine that U1A update received from its customer AS4 exhibits 425 violation of two RLP fields (those set by AS1 and AS3) and one of 426 them was set just two hops away. But U2A update exhibits that only 427 one RLP field was violated and that was set three hops back. Based 428 on this logic, AS5 may prefer U2A over U1A (even though U1A is a 429 customer route). This would be a good decision. However, Method Z 430 does not facilitate this kind of more rational decision process. 431 With Method Z, both updates U1B and U2B exhibit that they violated 432 only one RLP field (set by AS1 several hops away). AS5 may then 433 prefer U1B over U2B since U1B is from a customer, and that would be 434 bad decision. This illustrates that, due to more information in per- 435 hop RLP Fields, Method A seems to be operationally more beneficial 436 than Method Z. 438 Further, for detection and notification of neighbor AS's non- 439 compliance, Method A (per-hop RLP) is better than Method Z (single 440 RLP). With Method A, the bad behavior of AS4 would be explicitly 441 evident to AS5 since it violated AS3's (only two hops away) RLP field 442 as well. AS5 would alert AS4 and AS2 would alert AS1 about lack of 443 compliance (when Method A is used). With Method Z, the alerting 444 process may not be as expeditious. 446 3.7. Prevention of Route Leaks at Local AS: Intra-AS Messaging 448 Note: The intra-AS messaging for route leak prevention can be done 449 using a non-transitive BGP Community or Attribute. The Community- 450 based method is described below. For the BGP Attribute-based method, 451 see [I-D.ietf-idr-bgp-open-policy]. 453 3.7.1. Non-Transitive BGP Community for Intra-AS Messaging 455 The following procedure (or similar) for intra-AS messaging (i.e., 456 between ingress and egress routers) for prevention of route leaks is 457 a fairly common practice used by large ISPs. (Note: This information 458 was gathered from discussions on the NANOG mailing list 459 [Nanog-thread-June2016] as well as through private discussions with 460 operators of large ISP networks.) 462 Routes are tagged on ingress to an AS with communities for origin, 463 including the type of eBGP peer it was learned from (customer, 464 provider or lateral peer), geographic location, etc. The community 465 attributes are carried across the AS with the routes. These 466 communities are used along with additional logic in route policies to 467 determine which routes are to be announced to which eBGP peers and 468 which are to be dropped. In this process, the ISP's AS also ensures 469 that routes learned from a transit-provider or a lateral peer (i.e., 470 non-transit) at an ingress router are not leaked at an egress router 471 to another transit-provider or lateral peer. 473 Additionally, in many cases, ISP network operators' outbound policies 474 require explicit matches for expected communities before passing 475 routes. This helps ensure that that if an update has been entered 476 into the RIB-in but has missed its ingress community tagging (due to 477 a missing/misapplied ingress policy), it will not be inadvertently 478 leaked. 480 The above procedure (or a simplified version of it) is also 481 applicable when an AS consists of a single eBGP router. It is 482 recommended that all AS operators SHOULD implement the procedure 483 described above (or similar that is appropriate for their network) to 484 prevent route leaks that they have direct control over. 486 3.8. Stopgap Solution when Only Origin Validation is Deployed 488 A stopgap method is described here for detection and mitigation of 489 route leaks for the intermediate phase when OV is deployed but BGP 490 protocol on the wire is unchanged. The stopgap solution can be in 491 the form of construction of a prefix filter list from ROAs. A 492 suggested procedure for constructing such a list comprises of the 493 following steps: 495 o ISP makes a list of all the ASes (Cust_AS_List) that are in its 496 customer cone (ISP's own AS is also included in the list). (Some 497 of the ASes in Cust_AS_List may be multi-homed to another ISP and 498 that is OK.) 500 o ISP downloads from the RPKI repositories a complete list 501 (Cust_ROA_List) of valid ROAs that contain any of the ASes in 502 Cust_AS_List. 504 o ISP creates a list of all the prefixes (Cust_Prfx_List) that are 505 contained in any of the ROAs in Cust_ROA_List. 507 o Cust_Prfx_List is the allowed list of prefixes that is permitted 508 by the ISP's AS, and will be forwarded by the ISP to upstream 509 ISPs, customers, and peers. 511 o A route for a prefix that is not in Cust_Prfx_List but announced 512 by one of ISP's customers is 'marked' as a potential route leak. 513 Further, the ISP's router SHOULD prefer an alternate route that is 514 Valid (i.e., valid according to origin validation) and 'clean' 515 (i.e., not marked) over the 'marked' route. The alternate route 516 may be from a peer, transit provider, or different customer. 518 Special considerations regarding the above procedure may be needed 519 for DDoS mitigation service providers. They typically originate or 520 announce a DDoS victim's prefix to their own ISP on a short notice 521 during a DDoS emergency. Some provisions would need to be made for 522 such cases, and they can be determined with the help of inputs from 523 DDoS mitigation service providers. 525 For developing a list of all the ASes (Cust_AS_List) that are in the 526 customer cone of an ISP, the AS path based Outbound Route Filter 527 (ORF) technique [I-D.ietf-idr-aspath-orf] can be helpful (see 528 discussion in Section 3.5). 530 Another technique based on AS_PATH filters is described in 531 [Snijders]. This method is applicable to very large ISPs that have 532 lateral peering. For a pair of such very large ISPs, say A and B, 533 the method depends on ISP A communicating out-of-band (e.g., by 534 email) with ISP B about whether or not it (ISP A) has any transit 535 providers. This out-of-band knowledge enables ISP B to apply 536 suitable AS_PATH filtering criteria for routes involving the presence 537 of ISP A in the path and prevent certain kinds of route leaks (see 538 [Snijders] for details). 540 4. Security Considerations 542 This document requires no security considerations. See 543 [I-D.ietf-idr-route-leak-detection-mitigation] for security 544 considerations for the solution for route leaks detection and 545 mitigation. 547 5. IANA Considerations 549 This document has no IANA actions. 551 6. References 553 6.1. Normative References 555 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 556 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 557 DOI 10.17487/RFC4271, January 2006, 558 . 560 6.2. Informative References 562 [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., 563 and N. Katz-Bassett, "Investigating Interdomain Routing 564 Policies in the Wild", ACM Internet Measurement 565 Conference (IMC), October 2015, 566 . 568 [draft-dickson-sidr-route-leak-solns] 569 Dickson, B., "Route Leaks -- Proposed Solutions", IETF 570 Internet Draft (expired), March 2012, 571 . 574 [draft-kunzinger-idrp-ISO10747-01] 575 Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)", 576 IETF Internet Draft (expired), November 1994, 577 . 580 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 581 global coordination", IEEE/ACM Transactions on 582 Networking, December 2001, 583 . 586 [Gao-Rexford] 587 Freedman, M., "Interdomain Routing Policy", Princeton 588 University COS 461 Lecture Notes; Slides 25-27, Spring 589 2011, 590 . 593 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of 594 Interdomain Routing Policies", ACM SIGCOMM Computer 595 Communication Review, January 2014, 596 . 598 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in 599 Internet routing - Analysis based on BGP Community data", 600 IEEE ICC 2012, June 2012. 602 [I-D.ietf-idr-aspath-orf] 603 Hares, S. and K. Patel, "AS Path Based Outbound Route 604 Filter for BGP-4", draft-ietf-idr-aspath-orf-13 (work in 605 progress), December 2016. 607 [I-D.ietf-idr-bgp-open-policy] 608 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 609 Sriram, "Route Leak Prevention using Roles in Update and 610 Open messages", draft-ietf-idr-bgp-open-policy-03 (work in 611 progress), June 2018. 613 [I-D.ietf-idr-route-leak-detection-mitigation] 614 Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. 615 Robachevsky, "Methods for Detection and Mitigation of BGP 616 Route Leaks", draft-ietf-idr-route-leak-detection- 617 mitigation-08 (work in progress), March 2018. 619 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 620 kc. claffy, "AS Relationships, Customer Cones, and 621 Validation", IMC 2013, October 2013, 622 . 624 [Nanog-thread-June2016] 625 "Intra-AS messaging for route leak prevention", NANOG 626 Email List - Discussion Thread , June 2016, 627 . 630 [NIST-800-54] 631 Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway 632 Protocol Security", NIST Special Publication 800-54, July 633 2007, . 636 [proceedings-sixth-ietf] 637 Gross, P., "Proceedings of the April 22-24, 1987 Internet 638 Engineering Task Force", April 1987, 639 . 641 [RFC1105-obsolete] 642 Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 643 (BGP)", IETF RFC (obsolete), June 1989, 644 . 646 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 647 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 648 February 2015, . 650 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 651 and B. Dickson, "Problem Definition and Classification of 652 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 653 2016, . 655 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 656 Specification", RFC 8205, DOI 10.17487/RFC8205, September 657 2017, . 659 [Snijders] 660 Snijders, J., "Practical everyday BGP filtering with 661 AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA, 662 June 2016, . 665 [Wijchers] 666 Wijchers, B. and B. Overeinder, "Quantitative Analysis of 667 BGP Route Leaks", RIPE-69, November 2014, 668 . 671 Acknowledgements 673 The authors wish to thank Jared Mauch, Jeff Haas, Job Snijders, 674 Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy 675 Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes George, Job 676 Snijders, Chris Morrow, Sandy Murphy, Danny McPherson, and Eric 677 Osterweil for comments, suggestions, and critique. The authors are 678 also thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim 679 for their review and comments. 681 Contributors 683 The following people made significant contributions to this document 684 and should be considered co-authors: 686 Alexander Azimov 687 Qrator Labs 688 Email: aa@qrator.net 690 Brian Dickson 691 Independent 692 Email: brian.peter.dickson@gmail.com 694 Doug Montgomery 695 USA National Institute of Standards and Technology 696 Email: dougm@nist.gov 698 Keyur Patel 699 Arrcus 700 Email: keyur@arrcus.com 702 Andrei Robachevsky 703 Internet Society 704 Email: robachevsky@isoc.org 706 Eugene Bogomazov 707 Qrator Labs 708 Email: eb@qrator.net 710 Randy Bush 711 Internet Initiative Japan 712 Email: randy@psg.com 714 Author's Address 716 Kotikalapudi Sriram (editor) 717 USA National Institute of Standards and Technology 718 100 Bureau Drive 719 Gaithersburg, MD 20899 720 United States of America 722 Email: ksriram@nist.gov