idnits 2.17.1 draft-ietf-grow-filtering-threats-01.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 52 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 (October 18, 2013) is 3842 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-02 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 IMDEA Networks/UC3M 4 Intended status: Informational Pierre Francois 5 Expires: April 21, 2014 IMDEA Networks 6 October 18, 2013 8 Making BGP filtering a habit: Impact on policies 9 draft-ietf-grow-filtering-threats-01 11 Abstract 13 Network operators define their BGP policies based on the business 14 relationships that they maintain with their peers. By limiting the 15 propagation of BGP prefixes, an autonomous system avoids the 16 existence of flows between BGP peers that do not provide any 17 economical gain. This draft describes how unexpected traffic flows 18 can emerge in autonomous systems due to the filtering of overlapping 19 BGP prefixes by neighboring domains. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Filtering overlapping prefixes . . . . . . . . . . . . . . . . 3 57 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Remotely triggered filtering . . . . . . . . . . . . . . . 5 59 3. Uses of overlapping prefix filtering that create 60 unexpected traffic flows . . . . . . . . . . . . . . . . . . . 6 61 3.1. Unexpected traffic Flows . . . . . . . . . . . . . . . . . 7 62 3.1.1. Unexpected traffic flows caused by local filtering 63 of overlapping prefixes . . . . . . . . . . . . . . . 8 64 3.1.2. Unexpected traffic flows caused by remotely 65 triggered filtering of overlapping prefixes . . . . . 11 66 4. Techniques to detect unexpected traffic flows caused by 67 filtering of overlapping prefixes . . . . . . . . . . . . . . 14 68 4.1. Being the 'victim' of unexpected traffic flows . . . . . . 15 69 4.2. Being a contributor to the existence of unexpected 70 traffic flows in other networks . . . . . . . . . . . . . 15 71 5. Techniques to counter unexpected traffic flows due to the 72 filtering of overlapping prefixes . . . . . . . . . . . . . . 16 73 5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 17 74 5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 18 75 5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . . 18 76 5.2.2. Automatic overlapping prefix filtering . . . . . . . . 19 77 5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . . 19 78 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 It is common practice for network operators to propagate overlapping 85 prefixes along with the prefixes that they originate. It is also 86 possible for some Autonomous Systems (ASes) to apply different 87 policies to the overlapping (more specific) and the covering (less 88 specific) prefix. Some ASes can even benefit from filtering the 89 overlapping prefixes. 91 BGP makes independent, policy driven decisions for the selection of 92 the best path to be used for a given IP prefix. However, routers 93 must forward packets using the longest-prefix-match rule, which 94 "precedes" any BGP policy (RFC1812 [4]). Indeed, the existence of a 95 prefix p that is more specific than a prefix p' in the Forwarding 96 Information Base (FIB) will let packets whose destination matches p 97 be forwarded according to the next hop selected as best for p (the 98 overlapping prefix). This process takes place by disregarding the 99 policies applied in the control plane for the selection of the best 100 next-hop for p' (the covering prefix). When an Autonomous System 101 filters overlapping prefixes and forwards packets according to the 102 covering prefix, the discrepancy in the routing policies applied to 103 covering and overlapping prefixes can create unexpected traffic flows 104 that infringe the policies of other ASes still holding a path towards 105 the overlapping prefix. 107 This document presents examples of such cases and discusses solutions 108 to the problem. The objective of this draft is to shed light on the 109 use of prefix filtering by making the routing community aware of the 110 cases where the effects of filtering might turn to be negative for 111 the business of Internet Service Providers (ISPs). 113 The rest of the document is organized as follows: Section 2 114 illustrates the motivation to filter overlapping prefixes. In 115 Section 3, we provide some scenarios in which the filtering of 116 overlapping prefixes lead to the creation of unexpected traffic flows 117 on other ASes. Section 4 and Section 5 discuss some techniques that 118 ASes can use for, respectively, detect and react to unexpected 119 traffic flows. 121 2. Filtering overlapping prefixes 123 There are several scenarios where filtering an overlapping prefix is 124 relevant to the operations of an AS. In this section, we provide 125 examples of these scenarios. We differentiate cases in which the 126 filtering is performed locally from those where the filtering is 127 triggered remotely. These scenarios will be used as a base in 128 Section 3 for describing side effects bound with such practices. 130 2.1. Local filtering 132 Let us first analyze the scenario depicted in Figure 1. AS1 and AS2 133 are two autonomous systems spanning a large geographical area and 134 peering in 3 different physical locations. Let AS1 announce prefix 135 10.0.0.0/22 over all peering links with AS1. Additionally, let us 136 define that there is part of AS1's network which exclusively uses 137 prefix 10.0.0.0/24 and which is closer to a peering point than to 138 others. 140 To receive the traffic destined to prefix 10.0.0.0/24 on the link 141 closer to this subnet, AS1 could announce the overlapping prefix only 142 over this specific session. At the time of the establishment of the 143 peering, it can be defined by both ASes that hot potato routing would 144 happen in both directions of traffic. In other words, it was agreed 145 that each AS will deliver the traffic to the other AS on the nearest 146 peering link. In this scenario, it becomes relevant to AS2 to 147 enforce such practice by detecting the described situations and 148 automatically issuing the appropriate filtering. In this case, by 149 implementing these automatic procedures, AS2 would legitimately 150 detect and filter prefix 10.0.0.0/24. 152 ___....-----------....___ 153 ,.--' AS2 `--.. 154 ,' `. 155 | | 156 `._ _.' 157 `--..__ _,,.--' 158 . `'''-----------'''' | 159 | | | 160 | | | 161 10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22 162 | ___....-----------....___ |10.0.0.0/24 163 ,.--'AS1 `--.. 164 ,' ...........`. 165 | |10.0.0.0/24 | 166 `._ |........._.' 167 `--..__ _,,.--' 168 `'''-----------'''' 170 Figure 1: Basic scenario of local filtering 172 Local filtering could be required in other cases. For example, a 173 dual homed AS receiving an overlapping prefix from only one of its 174 providers. Figure 2 depicts a simple example of this case. 176 _..._ 177 ,' `. 178 / AS4 \ 179 | | 180 \ / 181 ,`-...-'. 182 / '. 183 10.0.0.0/22 ,' \ 184 10.0.0.0/24 / \ 10.0.0.0/22 185 ..:_ >..._ 186 ,' `. ,' `. 187 / AS2 \ / AS3 \ 188 | | | | 189 \ / \ / 190 `-...-', `-...-' 191 \ / 192 \ / 193 10.0.0.0/22 \_..._ '10.0.0.0/22 194 10.0.0.0/24,' `. 195 / AS1 \ 196 | | 197 \ / 198 `-...-' 200 Figure 2: Basic scenario of local filtering 202 In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and 203 AS3. Both ASes propagate the prefix to AS4. Additionally, AS1 204 advertises prefix 10.0.0.0/24 to AS2, which subsequently propagates 205 the prefix to AS4. 207 It is possible that AS4 resolves to filter the more specific prefix 208 10.0.0.0/24. One potential motivation could be the economical 209 preference of the path via AS2 over AS3. Another feasible reason is 210 the existence of a technical policy by AS4 of aggregating incoming 211 prefixes longer than /23. 213 The above examples illustrate two of the many motivations to 214 configure routing within an AS with the aim of ignoring more specific 215 prefixes. Operators have reported applying these filters in a manual 216 fashion [3]. The relevance of such practice led to investigate 217 automated filtering procedures in I-D.WHITE [5]. 219 2.2. Remotely triggered filtering 221 ISPs can tag the BGP paths that they propagate to neighboring ASes 222 with communities, in order to tweak the propagation behavior of the 223 ASes that handle these paths [1]. 225 Some ISPs allow their direct and indirect customers to use such 226 communities to let the receiving AS not export the path to some 227 selected neighboring AS. By combining communities, the prefix could 228 be advertised only to a given peer of the AS providing this feature. 229 Figure 3 illustrates an example of this case. 231 10.0.0.0/22 ,' \ 232 10.0.0.0/24 / \ 10.0.0.0/22 233 ..:_ >..._ 234 ,' `. ,' `. 235 / AS2 \________ / AS3 \ 236 | |/22 /22| | 237 \ / \ / 238 `-...-', `-...-' 239 \ / 240 \ / 241 10.0.0.0/22 \_..._ '10.0.0.0/22 242 10.0.0.0/24,' `. 243 / AS1 \ 244 | | 245 \ / 246 `-...-' 248 Figure 3: Remote triggered filtering 250 AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic 251 engineering purposes, AS1 could use communities to prevent AS2 from 252 announcing prefix 10.0.0.0/24 to AS3. 254 Such technique is useful for operators to tweak routing decisions in 255 order to align with complex transit policies. We will see in later 256 sections that by producing the same effect as filtering, they can 257 also lead to unexpected traffic flows at other, distant, ASes. 259 3. Uses of overlapping prefix filtering that create unexpected traffic 260 flows 262 In this section, we define the concept of unexpected traffic flows 263 and describe three configuration scenarios that lead to their 264 creation. Note that these examples do not capture all the cases 265 where such issues can take place. 267 3.1. Unexpected 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 AS1. 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 / AS1 \ / AS2 \ / AS3 \ 287 ( )-----( )-----( ) 288 \ / P4/p4 \ / \ P3/p3 / 289 `. ,' `. ,' `. ,' 290 '-----' '-----' '-----' 291 | 292 | 293 | 294 ,-----. 295 ,' `. 296 / AS4 \ 297 ( ) 298 \ P4/p4 / 299 `. ,' 300 '-----' 302 Figure 4: Prefix exchange among four autonomous systems 304 Although ISPs usually implement the aforementioned policies, 305 unexpected traffic flows may still appear. In Figure 4, unexpected 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 types 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 unexpected traffic flows on ASes. 311 We provide examples of these cases in the next sections. 313 3.1.1. Unexpected traffic flows caused by local filtering of 314 overlapping 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 unexpected 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 as best path to AS1 the one 364 received from AS3. 366 3.1.1.2. Unexpected 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 unexpected 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: Unexpected 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 using itself to 414 exchange traffic between AS4 and AS3. However, due to the 415 discrepancies of routes from the overlapping and covering prefixes, 416 unexpected traffic flows between AS4 and AS3 still exist on AS2's 417 network. This situation is economically detrimental for AS2, since 418 it forwards traffic from a peer to a non-customer neighbor. 420 3.1.1.3. Unexpected 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: Unexpected 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 would be forwarded towards AS2. Due to the 463 existence of a route to prefix 10.0.0.0/24, AS2 receives the traffic 464 heading to this prefix from AS4 and sends it to AS5. This situation 465 creates unexpected traffic flows that contradict AS2's BGP policy, 466 since the AS ends up forwarding traffic from a peer to a transit 467 network. 469 3.1.2. Unexpected traffic flows caused by remotely triggered filtering 470 of overlapping prefixes 472 We present a configuration scenario in which an AS, using the 473 mechanism described in Section 2.2, informs its provider to 474 selectively propagate an overlapping prefix, leading to the creation 475 of unexpected traffic flows in another AS. 477 3.1.2.1. Initial setup 479 Let AS1 be a customer of AS2 and AS3. AS1 owns 10.0.0.0/22, which it 480 advertises through AS2 and AS3. Additionally, AS2 and AS3 are peers. 482 Both AS2 and AS3 select A1's path as best, and propagate it to their 483 customers, providers, and peers. Some remote ASes will route traffic 484 destined to 10.0.0.1 through AS2 while others will route traffic 485 through AS3. 487 \ / \ / 488 /22 \ / /22 /22 \ / /22 489 ,-----. ,-----. 490 ,' `. ,' `. 491 / AS2 \ /22 / AS3 \ 492 ( )-------------( ) 493 \ / /22 \ / 494 `. ,' `. ,' 495 '-----; / '-----' 496 \ / 497 \ / 498 10.0.0.0/22\ /10.0.0.0/22 499 \ / 500 \ ,-----.' 501 ,' `. 502 / AS1 \ 503 ( ) 504 \ / 505 `. ,' 506 '-----' 508 Figure 8: Example scenario 510 3.1.2.2. Injection of an overlapping prefix 512 Let AS1 advertise 10.0.0.0/24 over AS3 only. AS3 would propagate 513 this prefix to its customers, providers, and peers, including AS2. 515 From AS2's point of view, the path towards 10.0.0.0/24 is a "peer 516 path" and AS2 will only advertise it to its customers. ASes in the 517 customer branch of AS2 will receive a path to the /24 that contains 518 AS3 and AS2. Some multi-homed customers of AS2 may also receive a 519 path through AS3, but not through AS2, from other peering or provider 520 links. Any remote AS that is not lying in the customer branch of 521 AS2, will receive a path for 10.0.0.0/24 through AS3 and not through 522 AS2. 524 \ / /22\ / /22 525 /22 \ / /22 /24 \ / /24 526 ,-----. ,-----. 527 ,' `. /22 ,' `. 528 / AS2 \ /24 / AS3 \ 529 ( /22:AS1 )-------------( /22:AS1 ) 530 \ /24:AS3 / /22 \ /24:AS1 / 531 /22 /`. ,' `. ,' 532 /24/ '-----; / '-----' 533 / \ / 534 ,---./ \ / 535 / \ 10.0.0.0/22\ /10.0.0.0/22 536 | AS4 ) \ / 10.0.0.0/24 537 \ / \ ,-----.' 538 `---' ,' `. 539 / AS1 \ 540 ( ) 541 \ / 542 `. ,' 543 '-----' 545 Figure 9: Injection of overlapping prefix 547 AS2 only receives traffic destined to 10.0.0.0/24 from its customers, 548 which it forwards to its peer AS3. Routing is consistent with usual 549 Internet Routing Policies in this case. AS3 could receive traffic 550 destined to 10.0.0.0/24 from its customers, providers, and peers, 551 which it directly forwards to its customer AS1. 553 3.1.2.3. Creation of unexpected traffic flows by limiting the scope of 554 the overlapping prefix 556 Now, let us assume that 10.0.0.0/24, which is propagated by AS1 to 557 AS3, is tagged to have AS3 only propagate that path to AS2, using the 558 techniques described in Section 2.2. 560 ,-------. 561 ,' `. 562 / AS5 \ 563 ( /22:AS2 ) 564 \ / 565 `. ,' 566 '-------' \ / \ / 567 /22 \ //22 /22 \ //22 568 ,-----. ,-----. 569 ,' `. /22 ,' `. 570 / AS2 \ /24 / AS3 \ 571 ( /22:AS1 )-------------( /22:AS1 ) 572 \ /24:AS3 / /22 \ /24:AS1 / 573 /22 /`. ,' `. ,' 574 /24/ '-----; / '-----' 575 / \ / 576 ,---./ \ / 577 / \ 10.0.0.0/22\ /10.0.0.0/22 578 ( AS4 ) \ / 10.0.0.0/24 579 \ / \ ,-----.' 580 `---' ,' `. 581 / AS1 \ 582 ( ) 583 \ / 584 `. ,' 585 '-----' 587 Figure 10: More Specific Injection 589 From AS2's point of view, such a path is a "peer path" and will only 590 be advertised by AS2 to its customers. 592 ASes that are not customers of AS2 will not receive a path for 593 10.0.0.0/24. These ASes will forward packets destined to 10.0.0.0/24 594 according to their routing state for 10.0.0.0/22. Let us assume that 595 AS5 is such an AS, and that its best path towards 10.0.0.0/22 is 596 through AS2. Then, packets sent towards 10.0.0.1 by AS5 will 597 eventually reach AS2. However, in the data-plane of the nodes of 598 AS2, the longest prefix match for 10.0.0.1 is 10.0.0.0/24, which is 599 reached through AS3, a peer of AS2. Since AS5 is not in the customer 600 branch of AS2, we are in a situation in which traffic flows between 601 non-customer ASes take place in AS2. 603 4. Techniques to detect unexpected traffic flows caused by filtering of 604 overlapping prefixes 606 We differentiate the techniques available for detecting unexpected 607 traffic flows caused by the described scenarios from the cases in 608 which the interested AS is the victim or contributor of such 609 operations. 611 4.1. Being the 'victim' of unexpected traffic flows 613 To detect if unexpected traffic flows are taking place in its 614 network, an ISP can monitor its traffic data and validate if any flow 615 entering the ISP network through a non-customer link is forwarded to 616 a non-customer next-hop. 618 As mentioned in Section 3.1, unexpected traffic flows might appear 619 due to different situations. To discover if the problem arose after 620 the filtering of prefixes by neighboring ASes, an operator can 621 analyze available BGP data. For instance, an ISP can seek for 622 overlapping prefixes for which the next-hop is through a provider (or 623 peer), while the next-hop for their covering prefix(es) is through a 624 client. Direct communication or looking glasses can be used to check 625 whether non-customer neighboring ASes are propagating a path towards 626 the covering prefix and not the path towards the overlapping prefix. 627 This situation should trigger a warning, as this would mean that ASes 628 in the surrounding area of the current AS are forwarding packets 629 based on the routing entry for the less specific prefix only. 631 4.2. Being a contributor to the existence of unexpected traffic flows 632 in other networks 634 It can be considered problematic to be causing unexpected traffic 635 flows on other ASes. This situation may appear as an abuse to the 636 network resources of other ISPs. 638 There may be justifiable reasons for one ISP to perform filtering, 639 either to enforce established policies or to provide prefix 640 advertisement scoping features to its customers. These can vary from 641 trouble-shooting purposes to business relationships implementations. 642 Restricting such features for the sake of avoiding the creation of 643 unexpected traffic flows is not a practical option. 645 Traffic data does not help an ISP detect that it is acting as a 646 contributor of the creation of the unexpected traffic flow. It is 647 thus advisable to obtain as much information as possible about the 648 Internet environment of the AS and assess the risks of filtering 649 overlapping prefixes before implementing them. 651 Monitoring the manipulation of the communities that implement the 652 scoping of prefixes is recommended to the ISPs that provide these 653 features. The monitored behavior should then be compared with their 654 terms of use. 656 5. Techniques to counter unexpected traffic flows due to the filtering 657 of overlapping prefixes 659 Network Operators can adopt different approaches with respect to 660 unexpected traffic flows. We classify these actions according to 661 whether they are anticipant or reactive. 663 Reactive approaches are those in which the operator tries to detect 664 the situations via monitoring and solve unexpected traffic flows, 665 manually, on a case-by-case basis. 667 Anticipant or preventive approaches are those in which the routing 668 system will not let the unexpected traffic flows actually take place 669 when the configuration scenario is set up. 671 We use the scenario depicted in Figure 11 to describe these two kinds 672 of approaches. Based on our analysis, we observe that anticipant 673 approaches can be complex to implement and can lead to undesired 674 repercussions. Therefore, we conclude that the reactive approach is 675 the more reasonable recommendation to deal with unexpected flows. 677 ____,,................______ 678 _,.---'''' `''---..._ 679 ,-'' AS5 `-. 680 [ / 681 -.._ __.-' 682 . `'---....______ ______...---'' 683 |/22 `''''''''''''''' | 684 |/24 |/22 | 685 | |/24 | 686 | | | 687 | |/22 |/22 688 | | |/24 689 _,,---.:_ _,,---.._ _,,---.._ 690 ,' `. ,' `. ,' `. 691 / AS4 \ / AS2 \ / AS3 \ 692 | |_________| | | | 693 | | /22 | | | | 694 '. ,' . ,' . ,' 695 `. ,' `. ,' `. ,' 696 ``---'' ``---'' ``---'' 697 | | 698 | |10.0.0.0/24 699 |10.0.0.0/22 |10.0.0.0/22 700 _;,..---------...._| 701 ,-'AS1 ``-. 702 /' `. 703 `. _, 704 `-.._ _,,,' 705 `''---------''' 707 Figure 11: Anticipant counter-measures - Base example 709 5.1. Reactive counter-measures 711 An operator who detects unexpected traffic flows originated by any of 712 the cases described in Section 3 can contact the ASes that are likely 713 to have performed the propagation tweaks, inform them of the 714 situation, and persuade them to change their behavior. 716 If the situation remains, the operator can implement prefix filtering 717 in order to stop the unexpected flows. The operator can decide to 718 perform this action over the session with the operator announcing the 719 overlapping prefix or over the session with the neighboring AS from 720 which it is receiving the traffic. Each of these options carry a 721 different repercussion for the affected AS. We describe briefly the 722 two alternatives. 724 o An operator can decide to stop announcing the covering prefix at 725 the peering session with the neighboring AS from which it is 726 receiving traffic to the overlapping prefix. In the example of 727 Figure 11, AS2 would filter out the prefix 10.0.0.0/22 from the 728 eBGP session with AS4. In this case, all the traffic heading to 729 the prefix 10.0.0.0/22 from AS1 would not longer traverse AS2. 730 AS2 should evaluate if solving the inconvenient originated by the 731 unexpected traffic flows are worth the loss of this traffic share. 732 o An operator can decide to filter-out the concerned overlapping 733 prefix at the peering session over which it was received. In the 734 example of Figure 11, AS2 would filter out the incoming prefix 735 10.0.0.0/24 from the eBGP session with AS5. As a result, the 736 traffic destined to that /24 would be forwarded by AS2 along its 737 link with AS1, despite the actions performed by AS1 to have this 738 traffic coming in through its link with AS3. However, as AS2 will 739 no longer possess a route to the overlapping prefix, it risks 740 losing the traffic share from customers different from AS1 to that 741 prefix. Furthermore, this action can generate conflicts between 742 AS2 and AS1, since AS2 does not follow the policy expressed by AS1 743 in its BGP announcements. 745 It is possible that the behavior from the neighboring AS that is 746 causing the unexpected traffic flows opposes the peering agreement. 747 In this case, an operator can account the amount of traffic that has 748 been subject to the unexpected flows and charge the peer for that 749 traffic. That is, the operator can claim that it has been a provider 750 of that peer for the traffic that transited between the two ASes. 752 5.2. Anticipant counter-measures 754 5.2.1. Access lists 756 An operator can configure its routers to install dynamically an 757 access-list made of the prefixes towards which the forwarding of 758 traffic from that interface would lead to unexpected traffic flows. 759 In the example of Figure 11, AS2 would install an access-list denying 760 packets matching 10.0.0.0/24 associated with the interface connecting 761 to AS4. As a result, traffic destined to that prefix would be 762 dropped, despite the existence of a valid route towards 10.0.0.0/22. 764 Note that this technique actually lets packets destined to a valid 765 prefix be dropped while they are sent from a neighboring AS that 766 cannot know about policy conflicts and hence had no means to avoid 767 the creation of unexpected traffic flows. 769 5.2.2. Automatic overlapping prefix filtering 771 As described in Section 3, filtering of overlapping prefixes can in 772 some scenarios lead to unexpected traffic flows. Nevertheless, 773 depending on the autonomous system implementing such practice, this 774 operation can prevent these cases. This can be illustrated using the 775 example described in Figure 11: if AS2 or AS3 filter prefix 776 10.0.0.0/24, there would be no unexpected traffic flow in AS2. 777 Nevertheless, as described in Section 5.1, the filtering of 778 overlapping prefixes can generate conflicts between AS1 and AS2, 779 since AS2 would not forward traffic according to AS1's policy. 780 Additionally, AS2 can lose traffic share for the overlapping prefix 781 from customers different from AS1. 783 5.2.3. Neighbor-specific forwarding 785 An operator can technically ensure that traffic destined to a given 786 prefix will be forwarded from an entry point of the network based 787 only on the set of paths that have been advertised over that entry 788 point. 790 As an example, let us analyze the scenario of Figure 11 from the 791 point of view of AS2. The edge router connecting to the AS4 forward 792 packets destined to prefix 10.0.0.0/24 towards AS5. Likewise, it 793 will forward packets destined to prefix 10.0.0.0/22 towards AS1. The 794 router, however, only propagates the path of the covering prefix 795 (10.0.0.0/22) to AS4. An operator could implement the necessary 796 techniques to force the edge router to forward packets coming from 797 AS4 based only on the paths propagated to AS4. Thus, the edge router 798 would forward packets destined to 10.0.0.0/24 towards AS1 in which 799 case no unexpected traffic flow would occur. 801 Different techniques could provide the functionality just described; 802 however, their technical implementation can be complex to design and 803 operate. [2] describes an approach to implement this behavior. 804 Similar to the solution described in Section 5.2.2, this approach 805 could create conflicts between AS2 and AS1, since the traffic 806 forwarding performed by A2 goes against the policy of AS1. 808 6. Conclusions 810 In this document, we described threats to policies of autonomous 811 systems caused by the filtering of overlapping prefixes performed by 812 external networks. We provide examples of scenarios in which 813 unexpected traffic flows are caused by these practices and introduce 814 some techniques for their detection and prevention. Analyzing the 815 different options for dealing with this kind of problems, we 816 recommend potential victims to implement monitoring systems that can 817 detect them and react to them according to the specific situation. 818 Although we observe that there are reasonable situations in which 819 ASes could filter overlapping prefixes, we encourage that network 820 operators implement this type of filters only after considering the 821 cases described in this document. 823 7. References 825 [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM 826 Computer Communication Review vol. 38, no. 2, pp. 55-59, 827 April 2008. 829 [2] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford, 830 "Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco 831 Systems, Routing 832 Symposium http://www.cs.princeton.edu/~jrex/talks/ 833 cisconag09.pdf, October 2009. 835 [3] "INIT7-RIPE63", . 838 [4] 840 [5] 843 [6] 845 Authors' Addresses 847 Camilo Cardona 848 IMDEA Networks/UC3M 849 Avenida del Mar Mediterraneo, 22 850 Leganes 28919 851 Spain 853 Email: juancamilo.cardona@imdea.org 854 Pierre Francois 855 IMDEA Networks 856 Avenida del Mar Mediterraneo, 22 857 Leganes 28919 858 Spain 860 Email: pierre.francois@imdea.org