idnits 2.17.1 draft-ietf-grow-filtering-threats-03.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2014) is 3551 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 634 looks like a reference -- Missing reference section? '2' on line 636 looks like a reference -- Missing reference section? '3' on line 638 looks like a reference -- Missing reference section? '4' on line 640 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). 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: February 5, 2015 IMDEA Networks 6 Paolo Lucente 7 Cisco Systems 8 August 4, 2014 10 Making BGP filtering a habit: Impact on policies 11 draft-ietf-grow-filtering-threats-03 13 Abstract 15 This document describes how unexpected traffic flows can emerge 16 across an autonomous system, as the result of other autonomous 17 systems filtering, or restricting the propagation of overlapping 18 prefixes. We provide a review of the techniques to detect the 19 occurrence of this issue and defend against it. 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 February 5, 2015. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4 58 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.1. Unexpected traffic flows caused by local filtering of 60 overlapping prefixes . . . . . . . . . . . . . . . . 5 61 2.2. Remote filtering . . . . . . . . . . . . . . . . . . . . 6 62 2.2.1. Unexpected traffic flows caused by remotely triggered 63 filtering of overlapping prefixes . . . . . . . . . . 7 64 3. Techniques to detect unexpected traffic flows caused by 65 filtering of overlapping prefixes . . . . . . . . . . . . . . 8 66 3.1. Existence of unexpected traffic flows within an AS . . . 8 67 3.2. Contribution to the existence of unexpected traffic flows 68 in another AS . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Techniques to counter unexpected traffic flows . . . . . . . 10 70 4.1. Reactive counter-measures . . . . . . . . . . . . . . . . 11 71 4.2. Anticipant counter-measures . . . . . . . . . . . . . . . 12 72 4.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 12 73 4.2.2. Neighbor-specific forwarding . . . . . . . . . . . . 13 74 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. References . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 It is common practice for network operators to propagate a more 86 specific (overlapping) prefix in the BGP routing system, along with 87 the covering prefix that they originate. It is also possible for 88 some Autonomous Systems (ASes) to apply different policies to the 89 overlapping and the covering prefix. 91 While BGP makes independent, policy driven decisions for the 92 selection of the best path to be used for a given IP prefix, routers 93 must forward packets using the longest-prefix-match rule, which 94 "precedes" any BGP policy (RFC1812 [1]). The existence of a prefix p 95 that is more specific than a prefix p' in the Forwarding Information 96 Base (FIB) will let packets whose destination matches p be forwarded 97 according to the next hop selected as best for p (the overlapping 98 prefix). This process takes place by disregarding the policies 99 applied in the control plane for the selection of the best next-hop 100 for p'. When an Autonomous System filters overlapping prefixes and 101 forwards packets according to the covering prefix, the discrepancy in 102 the routing policies applied to covering and overlapping prefixes can 103 create unexpected traffic flows that infringe the policies of other 104 ASes, still holding a path towards the overlapping prefix. 106 The objective of this draft is to shed light on possible side effects 107 associated with overlapping prefix filtering. This document presents 108 examples of such side effects and discusses approaches towards 109 solutions to the problem. 111 The rest of the document is organized as follows: In Section 2 we 112 provide some scenarios in which the filtering of overlapping prefixes 113 leads to the creation of unexpected traffic flows. Section 3 and 114 Section 4 discuss some techniques that ASes can use for, 115 respectively, detect and react to unexpected traffic flows. We 116 conclude in Section 5. 118 1.1. Terminology 120 Overlapping prefix: A prefix in the routing table with an address 121 range that is covered by another prefix present in the routing table. 123 Covering prefix: A prefix in the routing table with an address range 124 partially covered by other prefixes. 126 We re-use the definitions of customer-transit peering and settlement- 127 free peering of RFC4384 [2]. 129 Selective advertisement: The behavior of only advertising a self 130 originated BGP path for a prefix over a strict subset of the eBGP 131 sessions of the AS. 133 Selective propagation: The behavior of only propagating a BGP path 134 for a prefix over a strict subset of the eBGP sessions of an AS. 136 Local filtering: The behavior of explicitly ignoring a BGP path 137 received over an eBGP session. 139 Remote filtering: The behavior of triggering selective propagation of 140 a BGP path at a distant AS. Note that this is typically achieved by 141 tagging a self-originated path with BGP communities defined by the 142 distant AS. 144 Unexpected traffic flow: Traffic flowing between two neighboring ASes 145 of an AS, although the transit policy of that AS is to not provide 146 connectivity between these two neighbors. A traffic flow across an 147 AS, between two of its transit providers, or between a transit 148 provider and one of its settlement-free peers, are classical examples 149 of unexpected traffic flows. 151 2. Unexpected Traffic Flows 153 In this section, we describe how overlapping prefix filtering can 154 lead to unexpected traffic flows in other, remote, ASes. We 155 differentiate cases in which the filtering is performed locally from 156 those where the filtering is triggered remotely. 158 2.1. Local filtering 160 Local filtering can be motivated by different reasons, such as: (1) 161 Traffic engineering, where an AS wants to control their local 162 outbound traffic distribution using only the policy applied to the 163 covering prefix. (2) Enforcing contract compliance, where, for 164 instance, an AS avoids a settlement-free peer to attract traffic to 165 one link by using selective advertisement, when this is not allowed 166 by their peering agreement. 168 Figure 1 illustrates a scenario in which one AS is motivated to 169 perform local filtering due to outbound traffic engineering. The 170 figure depicts AS64504, and two of its neighboring ASes, AS64502 and 171 AS64505. AS 64504 has a settlement-free peering with AS64502 and is 172 a customer of AS64505. AS64504 receives from AS64505 prefixes 173 2001:DB8::/32 and 2001:DB8::/34, covering and overlapping prefixes, 174 respectively. AS64504 receives only the covering prefix 175 2001:DB8::/32 from AS64502. 177 ,-----. 178 / \ 179 ( AS64505 ) 180 \ / 181 `--+--' 182 2001:DB8::/32 | | 183 2001:DB8::/34 v | 184 | 185 ,--+--. 2001:DB8::/32 ,-----. 186 / \ <-- / \ 187 ( AS64504 )-------------( AS64502 ) 188 \ / \ / 189 `-----' `-----' 191 Figure 1: Local Filtering 193 Due to economical reasons, AS64504 might prefer to send traffic to 194 AS64502 instead of AS64505. However, even if paths received from 195 AS64502 are given a large local preference, routers in AS64504 will 196 still send traffic to prefix 2001:DB8::/34 via neighbor AS64505. 197 This situation may push AS64504 to apply an inbound filter for the 198 overlapping prefix, 2001:DB8::/34, on the session with AS64505. 199 After the filter is applied, traffic to the overlapping prefix will 200 be sent to AS64502 202 2.1.1. Unexpected traffic flows caused by local filtering of 203 overlapping prefixes 205 In this section, we show how the decision of AS64504 to perform local 206 filtering creates unexpected traffic flows in AS64502. Figure 2 207 shows the whole picture of the scenario; where AS64501 is a customer 208 of AS64503 and AS64502. AS64503 is a settlement-free peer with 209 AS64502. AS64503 and AS64502 are customers of AS64505. The AS 210 originating the two prefixes, AS64501, performs selective 211 advertisement with the overlapping prefix and only announces it to 212 AS64503. 214 After AS64504 locally filters the overlapping prefix, traffic from 215 AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502. 216 Because AS64502 receives the more specific prefix from AS64503, 217 traffic from AS64504 to 2001:DB8::/34 follows the path 218 AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are 219 implemented to avoid transporting traffic between AS64504 and 220 AS64503. However, due to the discrepancies of routes from the 221 overlapping and covering prefixes, unexpected traffic flows between 222 AS64504 and AS64503 exist in AS64502's network. 224 ____,,................______ 225 _,.---'''' `''---..._ 226 ,-'' AS64505 `-. 227 [ / 228 -.._ __.-' 229 . `'---....______ ______...---'' 230 + |/32 `''''''''''''''' | 231 | |/34 + |/32 | 232 v | v |/34 | 233 | | ^ | 234 | ^ |/32 | |/32 235 | + | + |/34 236 _,,---.:_ _,,---.._ _,,---.._ 237 ,' `. ,' `. ,' `. 238 / AS64504 \ <-+ / AS64502 \ / AS64503 \ 239 | |_________| |________| | 240 | | /32 | |/32 /32| | 241 '. ,' . ,' /34 . ,' 242 `. ,' `. ,' +-> <-+ `. ,' 243 ``---'' ``---'' ``---'' 244 | ^ | 245 ^ |2001:DB8::/32 | |2001:DB8::/32 246 | | + |2001:DB8::/34 247 + | _....---------...._| 248 ,-'AS64501 ``-. 249 /' `. 250 `. _, 251 `-.._ _,,,' 252 `''---------''' 254 Figure 2: Unexpected traffic flows due to local filtering 256 2.2. Remote filtering 258 ISPs can tag the BGP paths that they propagate to neighboring ASes 259 with communities, in order to tweak the propagation behavior of the 260 ASes that handle these paths [1]. Some ISPs allow their customers to 261 use such communities to let the receiving AS not export the path to 262 some selected neighboring ASes. By combining communities, the prefix 263 could be advertised only to a given peer of the AS providing this 264 feature. Remote filtering can be leveraged by an AS to, for 265 instance, limit the scope of prefixes and hence perform a more 266 granular inbound traffic engineering. 268 Figure 3 illustrates a scenario in which an AS uses BGP communities 269 to command its provider to selectively propagate an overlapping 270 prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501 271 originates prefix 2001:DB8::/32, which it advertises through AS64502 272 and AS64503. AS64502 and AS64503 are settlement-free peers. Let 273 AS64501 do selective advertisement and only propagate 2001:DB8::/34 274 over AS64503. AS64503 would normally propagate this prefix to its 275 customers, providers, and peers, including AS64502. 277 Let us consider that AS64501 decides to limit the scope of the 278 overlapping prefix. AS64501 can make this decision based on its 279 traffic engineering strategy. To achieve this, AS64501 can tag the 280 overlapping prefix with a set of communities that leads AS64503 to 281 only propagate the path to AS64502. 283 ^ \ / ^ ^ \ / ^ 284 | /32 \ / /32 | | /32 \ / /32 | 285 ,-----. ,-----. 286 ,' `. ,' `. 287 / AS64502 \ / AS64503 \ 288 ( )-------------( ) 289 \ / /32 /32 \ / 290 `. ,' -> /34 `. ,' 291 '-----; <- / '-----' 292 \ / 293 ^ \ / ^ 294 | \ / | 295 | \ / | 296 | \ ,-----.' | 2001:DB8::/32 297 | ,' `. | 2001:DB8::/34 298 2001:DB8::/32 +-- / AS64501 \ --+ 299 ( ) 300 \ / 301 `. ,' 302 '-----' 304 Figure 3: Remote triggered filtering 306 2.2.1. Unexpected traffic flows caused by remotely triggered filtering 307 of overlapping prefixes 309 Figure 4 expands the scenario from Figure 3 and includes other AS 310 peering with ASes 64502 and 64503. Due to the limitation on the 311 scope performed on the overlapping prefix, ASes that are not 312 customers of AS64502 will not receive a path for 2001:DB8::/34. 313 These ASes will forward packets destined to 2001:DB8::/34 according 314 to their routing state for 2001:DB8::/32. Let us assume that AS64505 315 is such an AS, and that its best path towards 2001:DB8::/32 is 316 through AS64502. Packets sent towards 2001:DB8::1 by AS64505 will 317 reach AS64502. However, in the data-plane of the nodes of AS64502, 318 the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is 319 reached through AS64503, a settlement-free peer of AS64502. Since 320 AS64505 is not in the customer branch of AS64502, we are in a 321 situation in which traffic flows between non-customer ASes take place 322 in AS64502. 324 ,-----. 325 ,' `. 326 / AS64505 \ 327 ( ) 328 \ / 329 `. ,' 330 '-----' 331 ^ \ / ^ ^ \ / ^ 332 | /32 \ / /32 | | /32 \ / /32 | 333 + ,-----. + + ,-----. + 334 ,' `. ,' `. 335 / AS64502 \ / AS64503 \ 336 ( )-------------( ) 337 ,-----. \ / /32 /32 \ / 338 ,' `.---------`. ,' +-> /34 `. ,' 339 / AS64504 \ /32 '-----; <-+ / '-----' 340 ( ) /34 \ / 341 \ / <-+ ^ \ / ^ 342 `. ,' | \ / | 343 '-----; | \ / | 344 | \ ,-----.' | 2001:DB8::/32 345 | ,' `. | 2001:DB8::/34 346 2001:DB8::/32 +--+ / AS64501 \ +--+ 347 ( ) 348 \ / 349 `. ,' 350 '-----' 352 Figure 4: Unexpected traffic flows due to remote triggered filtering 354 3. Techniques to detect unexpected traffic flows caused by filtering of 355 overlapping prefixes 357 3.1. Existence of unexpected traffic flows within an AS 359 To detect if unexpected traffic flows are taking place in its 360 network, an ISP can monitor its traffic data to check if it is 361 providing transit between two of its peers, although his policy is 362 configured to not provide such transit. IPFIX (RFC7011 [3]) is an 363 example of a technology that can be used to export information 364 regarding traffic flows across the network. Traffic information must 365 be analyzed under the perspective of the business relationships with 366 neighboring ASes. Open source tools such as [4] can be used to this 367 end. 369 Note that the AS detecting the unexpected traffic flow may simply 370 realize that his policy configuration is broken. The first 371 recommended action upon detection of an unexpected traffic flow is to 372 verify the correctness of the BGP configuration. 374 Once it has been assessed that the local configuration is correct, 375 the operator should check if the problem detected in the data-plane 376 arose due to filtering of BGP paths by neighboring ASes. The 377 operator should check if the destination address of the unexpected 378 traffic flow is locally routed as per an overlapping prefix only 379 received from non-customer peers. The operator should also checks if 380 there are paths to a covering prefix received from a customer, and 381 hence propagated to peers. If these two situations happen at the 382 same time, the neighboring AS at the entry point of the unexpected 383 flow is routing the traffic based on the covering prefix, although 384 the ISP is actually forwarding the traffic via non-customer links. 386 To detect the origin of the problem, human interaction or looking 387 glasses can be used in order to find out whether local filtering, 388 remote filtering, or selective propagation was performed on the 389 overlapping prefix. Due to the distributed nature and restricted 390 visibility of the steering of BGP policies, such analysis is deemed 391 to not identify the origin of the problem with guaranteed accuracy. 392 We are not aware, at the time of this writing, of any openly 393 available tool that can automatically perform this operation. 395 3.2. Contribution to the existence of unexpected traffic flows in 396 another AS 398 It can be considered problematic to be causing unexpected traffic 399 flows in other ASes. This situation may appear as an abuse to the 400 network resources of other ISPs. 402 There may be justifiable reasons for one ISP to perform filtering; 403 either to enforce established policies or to provide prefix 404 advertisement scoping features to its customers. These can vary from 405 trouble-shooting purposes to business relationship implementations. 406 Restricting the use of these features for the sake of avoiding the 407 creation of unexpected traffic flows is not a practical option. 409 It is advisable for an AS to assess the risks of filtering 410 overlapping prefixes before implementing them by obtaining as much 411 data information as possible about its surrounding routing 412 environment. The AS would need information of the routing policies 413 and the relationships among external ASes to detect if its actions 414 could trigger the appearance of unexpected traffic flows. With this 415 information, the operator could detect other ASes receiving the 416 overlapping prefix from non-customer ASes, while announcing the 417 covering prefix to other non-customer ASes. If the filtering of the 418 overlapping prefix leads other ASes to send traffic for the 419 overlapping prefix to these ASes, an unexpected traffic flow can 420 arise. However, the information required for this operation is 421 difficult to obtain, due to the distributed nature of BGP policies. 422 We are not aware, at the time of this writing, of any openly 423 available tool that can automatically perform this procedure. 425 4. Techniques to counter unexpected traffic flows 427 Network Operators can adopt different approaches with respect to 428 unexpected traffic flows. Note that due the complexity of inter- 429 domain routing policies, there is not a single solution that can be 430 applied to all situations. We provide potential solutions that ISPs 431 must evaluate against each particular case. We classify these 432 actions according to whether they are anticipant or reactive. 434 Reactive approaches are those in which the operator tries to detect 435 the situations via monitoring and solve unexpected traffic flows, 436 manually, on a case-by-case basis. 438 Anticipant or preventive approaches are those in which the routing 439 system will not let the unexpected traffic flows actually take place 440 when the scenario arises. 442 We use the scenario depicted in Figure 5 to describe these two kinds 443 of approaches. Based on our analysis, we observe that anticipant 444 approaches can be complex to implement and can lead to undesired 445 effects. Therefore, we conclude that the reactive approach is the 446 more reasonable recommendation to deal with unexpected flows. 448 ____,,................______ 449 _,.---'''' `''---..._ 450 ,-'' AS64505 `-. 451 [ / 452 -.._ __.-' 453 . `'---....______ ______...---'' 454 + |/32 `''''''''''''''' | 455 | |/34 + |/32 | 456 v | v |/34 | 457 | | ^ | 458 | ^ |/32 | |/32 459 | + | + |/34 460 _,,---.:_ _,,---.._ _,,---.._ 461 ,' `. ,' `. ,' `. 462 / AS64504 \ <-+ / AS64502 \ / AS64503 \ 463 | |_________| | | | 464 | | /32 | | | | 465 '. ,' . ,' . ,' 466 `. ,' `. ,' `. ,' 467 ``---'' ``---'' ``---'' 468 | ^ | 469 ^ |2001:DB8::/32 | |2001:DB8::/32 470 | | + |2001:DB8::/34 471 + | _....---------...._| 472 ,-'AS64501 ``-. 473 /' `. 474 `. _, 475 `-.._ _,,,' 476 `''---------''' 478 Figure 5: Counter-measures for unexpected traffic flows - Base 479 example 481 4.1. Reactive counter-measures 483 An operator who detects unexpected traffic flows originated by any of 484 the cases described in Section 2 can contact the ASes that are likely 485 to have performed the propagation tweaks, inform them of the 486 situation, and persuade them to change their behavior. 488 If the situation remains, the operator can implement prefix filtering 489 in order to stop the unexpected flows. The operator can decide to 490 perform this action over the session with the operator announcing the 491 overlapping prefix or over the session with the neighboring AS from 492 which it is receiving the traffic. Each of these options carry a 493 different repercussion for the affected AS. We describe briefly the 494 two alternatives. 496 o An operator can decide to stop announcing the covering prefix at 497 the peering session with the neighboring AS from which it is 498 receiving traffic to the overlapping prefix. In the example of 499 Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from 500 the eBGP session with AS64504. In this case, not all traffic 501 heading to the prefix 2001:DB8::/32 from AS64501 would no longer 502 traverse AS64502. AS64502 should evaluate if solving the issues 503 originated by the unexpected traffic flows are worth the loss of 504 this traffic share. 506 o An operator can decide to filter out the overlapping prefix at the 507 peering session over which it was received. In the example of 508 Figure 5, AS64502 would filter out the incoming prefix 509 2001:DB8::/34 from the eBGP session with AS64505. As a result, 510 the traffic destined to that /32 would be forwarded by AS64502 511 along its link with AS64501, despite the actions performed by 512 AS64501 to have this traffic coming in through its link with 513 AS64503. However, as AS64502 will no longer know a route to the 514 overlapping prefix, it risks losing the traffic share from 515 customers different from AS64501 to that prefix. Furthermore, 516 this action can generate conflicts between AS64502 and AS64501, 517 since AS64502 does not follow the routing information expressed by 518 AS64501 in its BGP announcements. 520 It is possible that the behavior of the neighboring AS causing the 521 unexpected traffic flows opposes the peering agreement. In this 522 case, an operator could account the amount of traffic that has been 523 subject to the unexpected flows, using traffic measurement protocols 524 such as IPFIX, and charge the peer for that traffic. That is, the 525 operator can claim that it has been a provider of that peer for the 526 traffic that transited between the two ASes. 528 4.2. Anticipant counter-measures 530 4.2.1. Access lists 532 An operator can configure its routers to install dynamically an 533 access-list made of the prefixes towards which the forwarding of 534 traffic from that interface would lead to unexpected traffic flows. 535 In the example of Figure 5, AS64502 would install an access-list 536 denying packets matching 2001:DB8::/34 associated with the interface 537 connecting to AS64504. As a result, traffic destined to that prefix 538 would be dropped, despite the existence of a valid route towards 539 2001:DB8::/32. 541 This technique actually lets packets destined to a valid prefix be 542 dropped while they are sent from a neighboring AS that may not know 543 about the policy conflict and hence had no means to avoid the 544 creation of unexpected traffic flows. For this reason, this 545 technique can be considered harmful and is thus not recommended for 546 implementation. 548 4.2.2. Neighbor-specific forwarding 550 An operator can technically ensure that traffic destined to a given 551 prefix will be forwarded from an entry point of the network based 552 only on the set of paths that have been advertised over that entry 553 point. 555 As an example, let us analyze the scenario of Figure 5 from the point 556 of view of AS64502. The edge router connecting to the AS64504 557 forwards packets destined to prefix 2001:DB8::/34 towards AS64505. 558 Likewise, it forwards packets destined to prefix 2001:DB8::/32 559 towards AS64501. The router, however, only propagates the path of 560 the covering prefix (2001:DB8::/32) to AS64504. An operator could 561 implement the necessary techniques to force the edge router to 562 forward packets coming from AS64504 based only on the paths 563 propagated to AS64504. Thus, the edge router would forward packets 564 destined to 2001:DB8::/34 towards AS64501 in which case no unexpected 565 traffic flow would occur. 567 Different techniques could provide this functionality; however, their 568 technical implementation can be complex to design and operate. An 569 operator could, for instance, employ Virtual Routing Forwarding (VRF) 570 tables RFC4364 [4] to store the routes announced to a neighbor and 571 forward traffic exclusively based on those routes. [2] describes this 572 solution and provides a description of its limitations. In the 573 future, new network protocols and architectures could provide this 574 functionality with less overhead for management and device resources. 576 Note that similarly to the solution described in Section 4.1, this 577 approach could create conflicts between AS64502 and AS64501, since 578 the traffic forwarding performed by AS64502 goes against the policy 579 of AS64501. 581 5. Conclusions 583 In this document, we described how the filtering of overlapping 584 prefixes can potentially create unexpected traffic flows in remote 585 ASes. We provided examples of scenarios in which unexpected traffic 586 flows are caused by these practices and introduce some techniques for 587 their detection and prevention. Analyzing the different options for 588 dealing with this kind of problems, we recommend ASes affected by 589 unexpected traffic flows to implement monitoring systems that can 590 detect them and react to them according to the specific situation. 591 Although we observe that there are reasonable situations in which 592 ASes could filter overlapping prefixes, we encourage network 593 operators to implement this type of filters considering the cases 594 described in this document. 596 6. Security Considerations 598 It is possible for an AS to use any of the methods described in this 599 document to deliberately reroute traffic flowing through another AS. 600 The objective of this document is to inform on this potential routing 601 security issue. 603 7. IANA Considerations 605 This document has no IANA actions. 607 8. Acknowledgments 609 The authors would like to thank Wes George, Jon Mitchell, and Bruno 610 Decraene for their useful suggestions and comments. 612 9. References 614 9.1. References 616 [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM 617 SIGCOMM Computer Communication Review vol. 38, no. 2, pp. 618 55-59, April 2008. 620 [2] Vanbever, L., Francois, P., Bonaventure, O., and J. 621 Rexford, "Customized BGP Route Selection Using BGP/MPLS 622 VPNs", Cisco Systems, Routing Symposium 623 http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf, 624 October 2009. 626 [3] "INIT7-RIPE63", . 629 [4] "pmacct project: IP accounting iconoclasm", 630 . 632 9.2. URIs 634 [1] http://www.ietf.org/rfc/rfc1812.txt 636 [2] http://www.ietf.org/rfc/rfc4384.txt 638 [3] http://www.ietf.org/rfc/rfc7011.txt 640 [4] http://www.ietf.org/rfc/rfc4364.txt 642 Authors' Addresses 644 Camilo Cardona 645 IMDEA Networks/UC3M 646 Avenida del Mar Mediterraneo, 22 647 Leganes 28919 648 Spain 650 Email: juancamilo.cardona@imdea.org 652 Pierre Francois 653 IMDEA Networks 654 Avenida del Mar Mediterraneo, 22 655 Leganes 28919 656 Spain 658 Email: pierre.francois@imdea.org 660 Paolo Lucente 661 Cisco Systems 662 170 W. Tasman Drive 663 San Jose, CA 95134 664 USA 666 Email: plucente@cisco.com