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