idnits 2.17.1 draft-cardona-filtering-threats-02.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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 50 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-white-grow-overlapping-routes-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Camilo Cardona 3 Internet-Draft Pierre Francois 4 Intended status: Informational IMDEA Networks 5 Expires: January 10, 2014 July 9, 2013 7 Making BGP filtering a habit: Impact on policies 8 draft-cardona-filtering-threats-02 10 Abstract 12 Network operators define their BGP policies based on the business 13 relationships that they maintain with their peers. By limiting the 14 propagation of BGP prefixes, an autonomous system avoids the 15 existence of flows between BGP peers that do not provide any 16 economical gain. This draft describes how undesired flows can emerge 17 in autonomous systems due to the filtering of overlapping BGP 18 prefixes by neighboring domains. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Filtering overlapping prefixes . . . . . . . . . . . . . . . . 3 56 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Remotely triggered filtering . . . . . . . . . . . . . . . 5 58 3. Uses of overlapping prefix filtering that create undesired 59 traffic flows . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Undesired Traffic Flows . . . . . . . . . . . . . . . . . 7 61 3.1.1. Undesired traffic flows caused by local filtering 62 of overlapping prefixes . . . . . . . . . . . . . . . 8 63 3.1.2. Undesired traffic flows caused by remotely 64 triggered filtering of overlapping prefixes . . . . . 11 65 4. Techniques to detect undesired traffic flows caused by 66 filtering of overlapping prefixes . . . . . . . . . . . . . . 14 67 4.1. Being the 'victim' . . . . . . . . . . . . . . . . . . . . 15 68 4.2. Being a contributor to the existence of undesired 69 traffic flows in other networks . . . . . . . . . . . . . 15 70 5. Techniques to counter undesired traffic flows due to the 71 filtering of overlapping prefixes . . . . . . . . . . . . . . 16 72 5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 17 73 5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 18 74 5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . . 18 75 5.2.2. Automatic filtering . . . . . . . . . . . . . . . . . 18 76 5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . . 18 77 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 It is common practice for network operators to propagate overlapping 84 prefixes along with the prefixes that they originate. It is also 85 possible for some Autonomous Systems (ASes) to apply different 86 policies to the overlapping (more specific) and the covering (less 87 specific) prefix. Some ASes can even benefit from filtering the 88 overlapping prefixes. 90 BGP makes independent, policy driven decisions for the selection of 91 the best path to be used for a given IP prefix. However, routers 92 must forward packets using the longest-prefix-match rule, which 93 "precedes" any BGP policy (RFC1812 [4]). Indeed, the existence of a 94 prefix p that is more specific than a prefix p' in the Forwarding 95 Information Base (FIB) will let packets whose destination matches p 96 be forwarded according to the next hop selected as best for p (the 97 overlapping prefix). This process takes place by disregarding the 98 policies applied in the control plane for the selection of the best 99 next-hop for p' (the covering prefix). When overlapping prefixes are 100 filtered and packets are forwarded according to the covering prefix, 101 the discrepancy in the routing policies applied to covering and 102 overlapping prefixes can create undesired traffic flows that infringe 103 the policies of Internet Service Providing (ISPs) still holding a 104 path towards the overlapping prefix. 106 This document presents examples of such cases and discusses solutions 107 to the problem. The objective of this draft is to shed light on the 108 use of prefix filtering by making the routing community aware of the 109 cases where the effects of filtering might turn to be negative for 110 the business of ISPs. 112 The rest of the document is organized as follows: Section 2 113 illustrates the motivation to filter overlapping prefixes. In 114 Section 3, we provide some scenarios in which the filtering of 115 overlapping prefixes lead to the creation of undesired traffic flows 116 on other ASes. Section 4 and Section 5 discuss some techniques that 117 ASes can use for, respectively, detect and react to undesired traffic 118 flows. 120 2. Filtering overlapping prefixes 122 There are several scenarios where filtering an overlapping prefix is 123 relevant to the operations of an AS. In this section, we provide 124 examples of these scenarios. We differentiate cases in which the 125 filtering is performed locally from those where the filtering is 126 triggered remotely. These scenarios will be used as a base in 127 Section 3 for describing side effects bound with such practices. 129 2.1. Local filtering 131 Let us first analyze the scenario depicted in Figure 1. AS1 and AS2 132 are two autonomous systems spanning a large geographical area and 133 peering in 3 different physical locations. Let AS1 announce prefix 134 10.0.0.0/22 over all peering links with AS1. Additionally, let us 135 define that there is part of AS1's network which exclusively uses 136 prefix 10.0.0.0/24 and which is closer to a peering point than to 137 others. 139 To receive the traffic destined to prefix 10.0.0.0/24 on the link 140 closer to this subnet, AS1 could announce the overlapping prefix only 141 over this specific session. At the time of the establishment of the 142 peering, it can be defined by both ASes that hot potato routing would 143 happen in both directions of traffic. In other words, it was agreed 144 that each AS will deliver the traffic to the other AS on the nearest 145 peering link. In this scenario, it becomes relevant to AS2 to 146 enforce such practice by detecting the described situations and 147 automatically issuing the appropriate filtering. In this case, by 148 implementing these automatic procedures, AS2 would legitimately 149 detect and filter prefix 10.0.0.0/24. 151 ___....-----------....___ 152 ,.--' AS2 `--.. 153 ,' `. 154 | | 155 `._ _.' 156 `--..__ _,,.--' 157 . `'''-----------'''' | 158 | | | 159 | | | 160 10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22 161 | ___....-----------....___ |10.0.0.0/24 162 ,.--'AS1 `--.. 163 ,' ...........`. 164 | |10.0.0.0/24 | 165 `._ |........._.' 166 `--..__ _,,.--' 167 `'''-----------'''' 169 Figure 1: Basic scenario of local filtering 171 Local filtering could be required in other cases. For example, a 172 dual homed AS receiving an overlapping prefix from only one of its 173 providers. Figure 2 depicts a simple example of this case. 175 _..._ 176 ,' `. 177 / AS4 \ 178 | | 179 \ / 180 ,`-...-'. 181 / '. 182 10.0.0.0/22 ,' \ 183 10.0.0.0/24 / \ 10.0.0.0/22 184 ..:_ >..._ 185 ,' `. ,' `. 186 / AS2 \ / AS3 \ 187 | | | | 188 \ / \ / 189 `-...-', `-...-' 190 \ / 191 \ / 192 10.0.0.0/22 \_..._ '10.0.0.0/22 193 10.0.0.0/24,' `. 194 / AS1 \ 195 | | 196 \ / 197 `-...-' 199 Figure 2: Basic scenario of local filtering 201 In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and 202 AS3. Both ASes propagate the prefix to AS4. Additionally, AS1 203 advertises prefix 10.0.0.0/24 to AS2, which subsequently propagates 204 the prefix to AS4. 206 It is possible that AS4 resolves to filter the more specific prefix 207 10.0.0.0/24. One potential motivation could be the economical 208 preference of the path via AS2 over AS3. Another feasible reason is 209 the existence of a technical policy by AS4 of aggregating incoming 210 prefixes longer than /23. 212 The above examples illustrate two of the many motivations to 213 configure routing within an AS with the aim of ignoring more specific 214 prefixes. Operators have reported applying these filters in a manual 215 fashion [3]. The relevance of such practice led to investigate 216 automated filtering procedures in I-D.WHITE [5]. 218 2.2. Remotely triggered filtering 220 ISPs can tag the BGP paths that they propagate to neighboring ASes 221 with communities, in order to tweak the propagation behavior of the 222 ASes that handle these paths [1]. 224 Some ISPs allow their direct and indirect customers to use such 225 communities to let the receiving AS not export the path to some 226 selected neighboring AS. By combining communities, the prefix could 227 be advertised only to a given peer of the AS providing this feature. 228 Figure 3 illustrates an example of this case. 230 10.0.0.0/22 ,' \ 231 10.0.0.0/24 / \ 10.0.0.0/22 232 ..:_ >..._ 233 ,' `. ,' `. 234 / AS2 \________ / AS3 \ 235 | |/22 /22| | 236 \ / \ / 237 `-...-', `-...-' 238 \ / 239 \ / 240 10.0.0.0/22 \_..._ '10.0.0.0/22 241 10.0.0.0/24,' `. 242 / AS1 \ 243 | | 244 \ / 245 `-...-' 247 Figure 3: Remote triggered filtering 249 AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic 250 engineering purposes, AS1 could use communities to prevent AS2 from 251 announcing prefix 10.0.0.0/24 to AS3. 253 Such technique is useful for operators to tweak routing decisions in 254 order to align with complex transit policies. We will see in later 255 sections that by producing the same effect as filtering, they can 256 also lead to undesired traffic flows at other, distant, ASes. 258 3. Uses of overlapping prefix filtering that create undesired traffic 259 flows 261 In this section we define the concept of undesired traffic flows and 262 describe three configuration scenarios that lead to their creation. 263 Note that these examples do not capture all the cases where such 264 issues can take place. More examples will be provided in future 265 revisions of this document. 267 3.1. Undesired Traffic Flows 269 The BGP policy of an Internet Service provider includes all actions 270 performed over its originated routes and the routes received 271 externally. One important part of the BGP policy is the selection of 272 the routes that are propagated to each neighboring AS. One of the 273 goals of these policies is to allow ISPs to avoid transporting 274 traffic between two ASes without economical gain. For instance, ISPs 275 typically propagate to their peers only routes coming from its 276 customers (RFC4384 [6]). We briefly illustrate this operation in 277 Figure 4. In the figure, AS2 is establishing a settlement free 278 peering with AS1 and AS3. AS2 receives prefix P3/p3, from AS3. AS2, 279 however, is not interested in transporting traffic from AS1 to AS3, 280 therefore it does not propagate the prefix to AS3. In the figure, we 281 also show a customer of AS2, AS4, which is announcing prefix P4/p4. 282 AS2 propagates this prefix to AS1. 284 ,-'''-.. ,-'''-.. ,-'''-.. 285 ,' \ ,' \ ,' \ 286 .' \ .' \ .' \ 287 | |------| | ----| P3/p3 | 288 \ AS1 / P4/p4\ AS2 / \ AS3/ 289 \ ,' \ ,' \ ,' 290 `-...-' `-...-' `-...-' 291 | 292 | 293 | 294 ,-'''-.. 295 ,' P4/p4 \ 296 .' \ 297 | | 298 \ AS4 / 299 \ ,' 300 `-...-' 302 Figure 4: Prefix exchange among four autonomous systems 304 Although ISPs usually implement the aforementioned policies, 305 undesired traffic flows may still appear. In Figure 4, undesired 306 traffic flows are created, when, despite AS2's policy, traffic 307 arriving from peer AS1 is received and transported to AS3 by AS2. 308 These type of traffic flows can arise due to a number of reasons. 309 Specifically, in this document we explain how the filtering of 310 overlapping prefixes might cause undesired traffic flows on ASes. We 311 provide examples of these cases in the next sections. 313 3.1.1. Undesired traffic flows caused by local filtering of overlapping 314 prefixes 316 In this section we describe cases in which an AS locally filters an 317 overlapping prefix. We show that, depending on the BGP policies 318 applied by surrounding ASes, this decision can lead to undesired 319 traffic flows. 321 3.1.1.1. Initial setup 323 We start by describing the basic scenario of this case in Figure 5. 325 ____,,................______ 326 _,.---'''' `''---..._ 327 ,-'' AS5 `-. 328 [ / 329 -.._ __.-' 330 . `'---....______ ______...---'' 331 |/22 `''''''''''''''' | 332 |/24 |/22 | 333 | |/24 | 334 | | | 335 | |/22 |/22 336 | |/24 |/24 337 _,,---.:_ _,,---.._ _,,---.._ 338 ,' `. ,' `. ,' `. 339 / AS4 \ / AS2 \ / AS3 \ 340 | |_________| |________| | 341 | | /22 | |/22 /22| | 342 '. ,' /24 . ,'/24 /24 . ,' 343 `. ,' `. ,' `. ,' 344 ``---'' ``---'' ``---'' 345 | | 346 |10.0.0.0/24 |10.0.0.0/24 347 |10.0.0.0/22 |10.0.0.0/22 348 | _....---------...._| 349 ,-'AS1 ``-. 350 /' `. 351 `. _, 352 `-.._ _,,,' 353 `''---------''' 355 Figure 5: Initial Setup Local 357 AS1 is a customer of AS2 and AS3. AS2, AS3, and AS4 are customers of 358 AS5. AS2 is establishing a peering with AS3 and AS4. AS1 is 359 announcing a covering prefix, 10.0.0.0/22, and an overlapping prefix 360 10.0.0.0/24 to its providers. In the initial setup, AS2 and AS3 361 announce the two prefixes to their peers and transit providers. AS4 362 receives both prefixes from its peer (AS2) and transit provider 363 (AS5). We will consider that AS5 chooses the path through AS3 to 364 reach AS1. 366 3.1.1.2. Undesired traffic flows by local filtering - Case 1 368 In the next scenarios, we show that if AS4 filters the incoming 369 overlapping prefix from AS5, there is a situation in which undesired 370 traffic flows are created on other ASes. 372 ____,,................______ 373 _,.---'''' `''---..._ 374 ,-'' AS5 `-. 375 [ / 376 -.._ __.-' 377 . `'---....______ ______...---'' 378 |/22 `''''''''''''''' | 379 |/24 |/22 | 380 | |/24 | 381 | | | 382 | |/22 |/22 383 | | |/24 384 _,,---.:_ _,,---.._ _,,---.._ 385 ,' `. ,' `. ,' `. 386 / AS4 \ / AS2 \ / AS3 \ 387 | |_________| |________| | 388 | | /22 | |/22 /22| | 389 '. ,' . ,' /24 . ,' 390 `. ,' `. ,' `. ,' 391 ``---'' ``---'' ``---'' 392 | | 393 | |10.0.0.0/24 394 |10.0.0.0/22 |10.0.0.0/22 395 | _,,..---------...._| 396 ,-'AS1 ``-. 397 /' `. 398 `. _, 399 `-.._ _,,,' 400 `''---------''' 402 Figure 6: Undesired traffic flows by local filtering - Case 1 404 Let us assume the scenario illustrated in Figure 6. For this case, 405 AS1 only propagates the overlapping prefix to AS3. AS4 receives the 406 overlapping prefix only from its transit provider, AS5. 408 AS4 now is in a situation in which it would be favorable for it to 409 filter the announcement of prefix 10.0.0.0/24 from AS5. 410 Subsequently, traffic from AS4 to prefix 10.0.0.0/24 is forwarded 411 towards AS2. Because AS2 receives the more specific prefix from AS3, 412 traffic from AS4 to prefix 10.0.0.0/24 follows the path AS4-AS2-AS3- 413 AS1. AS2's BGP policies are implemented to avoid AS2 to exchange 414 traffic between AS4 and AS3. However, due to the discrepancies of 415 routes from the overlapping and covering prefixes, undesired traffic 416 flows between AS4 and AS3 still exist on AS2's network. This 417 situation is economically detrimental for AS2, since it forwards 418 traffic from a peer to a non-customer neighbor. 420 3.1.1.3. Undesired traffic flows by local filtering - Case 2 422 ____,,................______ 423 _,.---'''' `''---..._ 424 ,-'' AS5 `-. 425 [ / 426 -.._ __.-' 427 . `'---....______ ______...---'' 428 |/22 `''''''''''''''' | 429 |/24 |/22 | 430 | |/24 | 431 | | | 432 | |/22 |/22 433 | | |/24 434 _,,---.:_ _,,---.._ _,,---.._ 435 ,' `. ,' `. ,' `. 436 / AS4 \ / AS2 \ / AS3 \ 437 | |_________| | | | 438 | | /22 | | | | 439 '. ,' . ,' . ,' 440 `. ,' `. ,' `. ,' 441 ``---'' ``---'' ``---'' 442 | | 443 | |10.0.0.0/24 444 |10.0.0.0/22 |10.0.0.0/22 445 _;,..---------...._| 446 ,-'AS1 ``-. 447 /' `. 448 `. _, 449 `-.._ _,,,' 450 `''---------''' 452 Figure 7: Undesired traffic flows after local filtering - Case 2 454 Let us assume a second case where AS2 and AS3 are not peering and AS1 455 only propagates the overlapping prefix to AS3. AS4 receives the 456 overlapping prefix only from its transit provider, AS5. This case is 457 illustrated in Figure 7. 459 Similar to the scenario described in Section 3.1.1.2, AS4 is in a 460 situation in which it would be favorable to filter the announcement 461 of prefix 10.0.0.0/24 from AS5. Subsequently, traffic from AS4 to 462 prefix 10.0.0.0/24 is forwarded towards AS2. Due to the existence of 463 a route to prefix 10.0.0.0/24, AS2 receives the traffic heading to 464 this prefix from AS4, and sends it to AS5. This situation creates 465 undesired traffic flows that contradict AS2's BGP policy, since the 466 AS ends up forwarding traffic from a peer to a transit network. 468 3.1.2. Undesired traffic flows caused by remotely triggered filtering 469 of overlapping prefixes 471 We present a configuration scenario in which an AS, using the 472 mechanism described in Section 2.2, informs its provider to 473 selectively propagate an overlapping prefix, leading to the creation 474 of undesired traffic flows in another AS. 476 3.1.2.1. Initial setup 478 Let AS1 be a customer of AS2 and AS3. AS1 owns 10.0.0.0/22, which it 479 advertises through AS2 and AS3. Additionally, AS2 and AS3 are peers. 481 Both AS2 and AS3 select A1's path as best, and propagate it to their 482 customers, providers, and peers. Some remote ASes will route traffic 483 destined to 10.0.0.1 through AS2 while others will route traffic 484 through AS3. 486 \ / \ / 487 /22 \ / /22 /22 \ / /22 488 ,-----. ,-----. 489 ,' `. ,' `. 490 / AS2 \ /22 / AS3 \ 491 ( )-------------( ) 492 \ / /22 \ / 493 `. ,' `. ,' 494 '-----; / '-----' 495 \ / 496 \ / 497 10.0.0.0/22\ /10.0.0.0/22 498 \ / 499 \ ,-----.' 500 ,' `. 501 / AS1 \ 502 ( ) 503 \ / 504 `. ,' 505 '-----' 507 Figure 8: Example scenario 509 3.1.2.2. Injection of an overlapping prefix 511 Let AS1 advertise 10.0.0.0/24 over AS3 only. AS3 would propagate 512 this prefix to its customers, providers, and peers, including AS2. 514 From AS2's point of view, the path towards 10.0.0.0/24 is a "peer 515 path" and AS2 will only advertise it to its customers. ASes in the 516 customer branch of AS2 will receive a path to the /24 that contains 517 AS3 and AS2. Some multi-homed customers of AS2 may also receive a 518 path through AS3, but not through AS2, from other peering or provider 519 links. Any remote AS that is not lying in the customer branch of 520 AS2, will receive a path for 10.0.0.0/24 through AS3 and not through 521 AS2. 523 \ / /22\ / /22 524 /22 \ / /22 /24 \ / /24 525 ,-----. ,-----. 526 ,' `. /22 ,' `. 527 / AS2 \ /24 / AS3 \ 528 ( /22:AS1 )-------------( /22:AS1 ) 529 \ /24:AS3 / /22 \ /24:AS1 / 530 /22 /`. ,' `. ,' 531 /24/ '-----; / '-----' 532 / \ / 533 ,---./ \ / 534 / \ 10.0.0.0/22\ /10.0.0.0/22 535 | AS4 ) \ / 10.0.0.0/24 536 \ / \ ,-----.' 537 `---' ,' `. 538 / AS1 \ 539 ( ) 540 \ / 541 `. ,' 542 '-----' 544 Figure 9: Injection of overlapping prefix 546 AS2 only receives traffic destined to 10.0.0.0/24 from its customers, 547 which it forwards to its peer AS3. Routing is consistent with usual 548 Internet Routing Policies in this case. AS3 could receive traffic 549 destined to 10.0.0.0/24 from its customers, providers, and peers, 550 which it directly forwards to its customer AS1. 552 3.1.2.3. Creation of undesired traffic flows by limiting the scope of 553 the overlapping prefix 555 Now, let us assume that 10.0.0.0/24, which is propagated by AS1 to 556 AS3, is tagged to have AS3 only propagate that path to AS2, using the 557 techniques described in Section 2.2. 559 ,-------. 560 ,' `. 561 / AS5 \ 562 ( /22:AS2 ) 563 \ / 564 `. ,' 565 '-------' \ / \ / 566 /22 \ //22 /22 \ //22 567 ,-----. ,-----. 568 ,' `. /22 ,' `. 569 / AS2 \ /24 / AS3 \ 570 ( /22:AS1 )-------------( /22:AS1 ) 571 \ /24:AS3 / /22 \ /24:AS1 / 572 /22 /`. ,' `. ,' 573 /24/ '-----; / '-----' 574 / \ / 575 ,---./ \ / 576 / \ 10.0.0.0/22\ /10.0.0.0/22 577 ( AS4 ) \ / 10.0.0.0/24 578 \ / \ ,-----.' 579 `---' ,' `. 580 / AS1 \ 581 ( ) 582 \ / 583 `. ,' 584 '-----' 586 Figure 10: More Specific Injection 588 From AS2's point of view, such a path is a "peer path" and will only 589 be advertised by AS2 to its customers. 591 ASes that are not customers of AS2 will not receive a path for 592 10.0.0.0/24. These ASes will forward packets destined to 10.0.0.0/24 593 according to their routing state for 10.0.0.0/22. Let us assume that 594 AS5 is such an AS, and that its best path towards 10.0.0.0/22 is 595 through AS2. Then, packets sent towards 10.0.0.1 by AS5 will 596 eventually reach AS2. However, in the data-plane of the nodes of 597 AS2, the longest prefix match for 10.0.0.1 is 10.0.0.0/24, which is 598 reached through AS3, a peer of AS2. Since AS5 is not in the customer 599 branch of AS2, we are in a situation in which traffic flows between 600 non-customer AS take place in AS2. 602 4. Techniques to detect undesired traffic flows caused by filtering of 603 overlapping prefixes 605 We differentiate the techniques available for detecting undesired 606 traffic flows caused by the described scenarios from the cases in 607 which the interested AS is the victim or contributor of such 608 operations. 610 4.1. Being the 'victim' 612 To detect if undesired traffic flows are taking place in its network, 613 an ISP can monitor its traffic data and validate if any flow entering 614 the ISP network through a non-customer link is forwarded to a non- 615 customer next-hop. 617 As mentioned in Section 3.1, undesired traffic flows might appear due 618 to different situations. To discover if the problem arose after the 619 filtering of prefixes by neighboring ASes, an operator can analyze 620 available BGP data. For instance, an ISP can seek for overlapping 621 prefixes for which the next-hop is through a provider (or peer), 622 while the next-hop for their covering prefix(es) is through a client. 623 Direct communication or looking glasses can be used to check whether 624 non-customer neighboring ASes are propagating a path towards the 625 covering prefix to their own customers, peers, or providers. This 626 should trigger a warning, as this would mean that ASes in the 627 surrounding area of the current AS are forwarding packets based on 628 the routing entry for the less specific prefix only. 630 4.2. Being a contributor to the existence of undesired traffic flows in 631 other networks 633 It can be considered problematic to be causing undesired traffic 634 flows on other ASes. This situation may appear as an abuse to the 635 network resources of other ISPs. 637 There may be justifiable reasons for one ISP to perform filtering, 638 either to enforce established policies or to provide prefix 639 advertisement scoping features to its customers. These can vary from 640 trouble-shooting purposes to business relationships implementations. 641 Restricting such features for the sake of avoiding the creation of 642 undesired traffic flows is not a practical option. 644 Traffic data does not help an ISP detect that it is acting as a 645 contributor of the creation of the undesired traffic flow. It is 646 thus advisable to obtain as much information as possible about the 647 Internet environment of the AS and assess the risks of filtering 648 overlapping prefixes before implementing them. 650 Monitoring the manipulation of the communities that implement the 651 scoping of prefixes is recommended to the ISPs that provide these 652 features. The monitored behavior should then be faced against their 653 terms of use. 655 5. Techniques to counter undesired traffic flows due to the filtering 656 of overlapping prefixes 658 Network Operators can adopt different approaches with respect to 659 undesired traffic flows. We classify these actions according to 660 whether they are anticipant or reactive. 662 Reactive approaches are those in which the operator tries to detect 663 the situations and solve undesired traffic flows, manually, on a 664 case-by-case basis. 666 Anticipant or preventive approaches are those in which the routing 667 system will not let the undesired traffic flows actually take place 668 when the configuration scenario is set up. 670 We will describe these two kinds of approaches in the following part 671 of this Section. We will use the scenario depicted in Figure 11 to 672 provide examples for the different techniques. 674 ____,,................______ 675 _,.---'''' `''---..._ 676 ,-'' AS5 `-. 677 [ / 678 -.._ __.-' 679 . `'---....______ ______...---'' 680 |/22 `''''''''''''''' | 681 |/24 |/22 | 682 | |/24 | 683 | | | 684 | |/22 |/22 685 | | |/24 686 _,,---.:_ _,,---.._ _,,---.._ 687 ,' `. ,' `. ,' `. 688 / AS4 \ / AS2 \ / AS3 \ 689 | |_________| | | | 690 | | /22 | | | | 691 '. ,' . ,' . ,' 692 `. ,' `. ,' `. ,' 693 ``---'' ``---'' ``---'' 694 | | 695 | |10.0.0.0/24 696 |10.0.0.0/22 |10.0.0.0/22 697 _;,..---------...._| 698 ,-'AS1 ``-. 699 /' `. 700 `. _, 701 `-.._ _,,,' 702 `''---------''' 704 Figure 11: Anticipant counter-measures - Base example 706 5.1. Reactive counter-measures 708 An operator who detects that its policies are threatened by undesired 709 traffic flows can contact the ASes that are likely to have performed 710 the propagation tweaks, inform them of the situation and persuade 711 them to change their behavior. 713 For some cases, if the external ASes maintain their behavior, an 714 operator can account the amount of traffic that has been subject to 715 the undesired flows and charge the peer for that traffic. That is, 716 the operator can claim that it has been a provider of that peer for 717 the traffic that transited between the two ASes. 719 An operator can decide to filter-out the concerned overlapping prefix 720 at the peering session over which it was received. In the example of 721 Figure 11, AS2 would filter out the incoming prefix 10.0.0.0/24 from 722 the eBGP session with AS5. As a result, the traffic destined to that 723 /24 would be forwarded by AS2 along its link with AS1, despite the 724 actions performed by AS1 to have this traffic coming in through its 725 link with AS3. 727 5.2. Anticipant counter-measures 729 5.2.1. Access lists 731 An operator can configure its routers to install dynamically an 732 access-list made of the prefixes towards which the forwarding of 733 traffic from that interface would lead to undesired traffic flows. 734 Note that this technique actually lets packets destined to a valid 735 prefix be dropped while they are sent from a neighboring AS that 736 cannot know about policy conflicts and hence had no means to avoid 737 the creation of undesired traffic flows. 739 In the example of Figure 11, AS2 would install an access-list denying 740 packets matching 10.0.0.0/24 associated with the interface connecting 741 to AS4. As a result, traffic destined to that prefix would be 742 dropped, despite the existence of a valid route towards 10.0.0.0/22. 744 5.2.2. Automatic filtering 746 As described in Section 3, filtering of overlapping prefixes can in 747 some scenarios lead to undesired traffic flows. Nevertheless, 748 depending on the autonomous system implementing such practice, this 749 operation can prevent these cases. This can be illustrated using the 750 example described in Figure 11: if AS2 or AS3 filter prefix 751 10.0.0.0/24, there would be no undesired traffic flow in AS2. 753 5.2.3. Neighbor-specific forwarding 755 An operator can technically ensure that traffic destined to a given 756 prefix will be forwarded from an entry point of the network based 757 only on the set of paths that have been advertised over that entry 758 point. 760 As an example, let us analyze the scenario of Figure 11 from the 761 point of view of AS2. The edge router connecting to the AS4 forward 762 packets destined to prefix 10.0.0.0/24 towards AS5. Likewise, it 763 will forward packets destined to prefix 10.0.0.0/22 towards AS1. The 764 router, however, only propagates the path of the covering prefix 765 (10.0.0.0/22) to AS4. An operator could implement the necessary 766 techniques to force the edge router to forward packets coming from 767 AS4 based only on the paths propagated to AS4. Thus, the edge router 768 would forward packets destined to 10.0.0.0/24 towards AS1 in which 769 case no undesired traffic flow would occur. This functionality could 770 be implemented in different ways. [2] describes an approach to 771 implement this Behavior. 773 6. Conclusions 775 In this document, we described threats to policies of autonomous 776 systems caused by the filtering of overlapping prefixes by external 777 networks. We provide examples of scenarios in which undesired 778 traffic flows are caused by these practices and introduce some 779 techniques for their detection and prevention. We observe that there 780 are reasonable situations in which ASes could filter overlapping 781 prefixes, however, we encourage that network operators implement this 782 type of filters only after considering the cases described in this 783 document. 785 7. References 787 [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM 788 Computer Communication Review vol. 38, no. 2, pp. 55-59, 789 April 2008. 791 [2] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford, 792 "Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco 793 Systems, Routing 794 Symposium http://www.cs.princeton.edu/~jrex/talks/ 795 cisconag09.pdf, October 2009. 797 [3] "INIT7-RIPE63", . 800 [4] 802 [5] 805 [6] 807 Authors' Addresses 809 Camilo Cardona 810 IMDEA Networks 811 Avenida del Mar Mediterraneo, 22 812 Leganes 28919 813 Spain 815 Email: juancamilo.cardona@imdea.org 817 Pierre Francois 818 IMDEA Networks 819 Avenida del Mar Mediterraneo, 22 820 Leganes 28919 821 Spain 823 Email: pierre.francois@imdea.org