idnits 2.17.1 draft-ietf-grow-filtering-threats-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 08, 2015) is 3093 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: May 11, 2016 Paolo Lucente 6 Cisco Systems 7 November 08, 2015 9 Impact of BGP filtering on Inter-Domain Routing Policies 10 draft-ietf-grow-filtering-threats-08 12 Abstract 14 This document describes how unexpected traffic flows can emerge 15 across an autonomous system, as the result of other autonomous 16 systems filtering, or restricting the propagation of more specific 17 prefixes. We provide a review of the techniques to detect the 18 occurrence of this issue and defend against it. 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 May 11, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4 57 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. Unexpected traffic flows caused by local filtering of 59 more specific prefixes . . . . . . . . . . . . . . . 5 60 2.2. Remote filtering . . . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Unexpected traffic flows caused by remotely triggered 62 filtering of more specific prefixes . . . . . . . . . 7 63 3. Techniques to detect unexpected traffic flows caused by 64 filtering of more specific prefixes . . . . . . . . . . . . . 8 65 3.1. Existence of unexpected traffic flows within an AS . . . 8 66 3.2. Contribution to the existence of unexpected traffic flows 67 in another AS . . . . . . . . . . . . . . . . . . . . . . 9 68 4. Techniques to Traffic Engineer unexpected flows . . . . . . . 10 69 4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11 70 4.2. Proactive measures . . . . . . . . . . . . . . . . . . . 12 71 4.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 12 72 4.2.2. Neighbor-specific forwarding . . . . . . . . . . . . 13 73 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 It is common practice for network operators to propagate a more 85 specific prefix in the BGP routing system, along with the less 86 specific prefix that they originate. It is also possible for some 87 Autonomous Systems (ASes) to apply different policies to the more 88 specific and the less specific prefix. 90 Although BGP makes independent, policy driven decisions for the 91 selection of the best path to be used for a given IP prefix, routers 92 must forward packets using the longest-prefix-match rule, which 93 "precedes" any BGP policy (RFC1812 [RFC1812]). 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 more specific 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'. When an Autonomous System filters more specific 100 prefixes and forwards packets according to the less specific prefix, 101 the discrepancy among the routing policies applied to the less and 102 the more specific prefixes can create unexpected traffic flows. 103 These may infringe the policies of other ASes, still holding a path 104 towards the more specific prefix. 106 The objective of this draft is to shed light on possible side effects 107 associated with more specific prefix filtering. Such actions can be 108 explained by traffic engineering action, misconfiguration, or 109 malicious intent. This document presents examples of such side 110 effects and discusses approaches towards solutions to the problem. 112 The rest of the document is organized as follows: In Section 2 we 113 provide some scenarios in which the filtering of more specific 114 prefixes leads to the creation of unexpected traffic flows. 115 Section 3 and Section 4 discuss some techniques that ASes can use 116 for, respectively, detecting and reacting to unexpected traffic 117 flows. The document concludes in Section 5. 119 1.1. Terminology 121 More specific prefix: A prefix in the routing table with an address 122 range that is covered by a shorter prefix also present in the routing 123 table. 125 Less specific prefix: A prefix in the routing table with an address 126 range partially covered by other prefixes. 128 This document reuses the definitions of customer-transit peering and 129 settlement-free peering of RFC4384 [RFC4384]. 131 Selective advertisement: The behavior of only advertising a self 132 originated BGP path for a prefix over a strict subset of the eBGP 133 sessions of the AS. 135 Selective propagation: The behavior of only propagating a BGP path 136 for a prefix over a strict subset of the eBGP sessions of an AS. 138 Local filtering: The behavior of explicitly ignoring a BGP path 139 received over an eBGP session. 141 Remote filtering: The behavior of triggering selective propagation of 142 a BGP path at a distant AS. Note that this is typically achieved by 143 tagging a self-originated path with BGP communities defined by the 144 distant AS. 146 Unexpected traffic flow: Traffic flowing between two neighboring ASes 147 of an AS, although the transit policy of that AS is to not provide 148 connectivity between these two neighbors. A traffic flow across an 149 AS, between two of its transit providers, or between a transit 150 provider and one of its settlement-free peers, are classical examples 151 of unexpected traffic flows. 153 2. Unexpected Traffic Flows 155 In this section, we describe how more specific prefix filtering can 156 lead to unexpected traffic flows in other, remote, ASes. We 157 differentiate cases in which the filtering is performed locally from 158 those where the filtering is triggered remotely. 160 2.1. Local filtering 162 Different reasons motivate local filtering, for example: (1) Traffic 163 engineering, where an AS wants to control its local outbound traffic 164 distribution using only the policy applied to the less specific 165 prefix. Such a practice was notably documented in [INIT7-RIPE63] (2) 166 Enforcing contract compliance, where, for instance, an AS avoids a 167 settlement-free peer to attract traffic to one link by using 168 selective advertisement, when this is not allowed by their peering 169 agreement. (3) The need for Forwarding Information Base memory 170 preservation sometimes pushes ISP operators to filter more specific 171 prefixes. 173 Figure 1 illustrates a scenario where one AS performs local filtering 174 due to outbound traffic engineering. The figure depicts AS64504, and 175 two of its neighboring ASes, AS64502, and AS64505. AS64504 has a 176 settlement-free peering with AS64502 and is a customer of AS64505. 177 AS64504 receives from AS64505 prefixes 2001:DB8::/32 and 178 2001:DB8::/34. AS64504 only receives the less specific prefix 179 2001:DB8::/32 from AS64502. 181 ,-----. 182 / \ 183 ( AS64505 ) 184 \ / 185 `--+--' 186 2001:DB8::/32 | | 187 2001:DB8::/34 v | 188 | 189 ,--+--. 2001:DB8::/32 ,-----. 190 / \ <-- / \ 191 ( AS64504 )-------------( AS64502 ) 192 \ / \ / 193 `-----' `-----' 195 Figure 1: Local Filtering 197 Due to economic reasons, AS64504 might prefer to send traffic to 198 AS64502 instead of AS64505. However, even if paths received from 199 AS64502 are given a large local preference, routers in AS64504 will 200 still send traffic to prefix 2001:DB8::/34 via neighbor AS64505. 201 This situation may push AS64504 to apply an inbound filter for the 202 more specific prefix, 2001:DB8::/34, on the session with AS64505. 203 After applying the filter, AS64504 will send traffic for the more 204 specific prefix to AS64502. 206 2.1.1. Unexpected traffic flows caused by local filtering of more 207 specific prefixes 209 In this section, we show how the decision of AS64504 to perform local 210 filtering creates unexpected traffic flows in AS64502. Figure 2 211 shows the whole picture of the scenario; where AS64501 is a customer 212 of AS64503 and AS64502. AS64503 is a settlement-free peer with 213 AS64502. AS64503 and AS64502 are customers of AS64505. The AS 214 originating the two prefixes, AS64501, performs selective 215 advertisement with the more specific prefix and only announces it to 216 AS64503. 218 After AS64504 locally filters the more specific prefix, traffic from 219 AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502. 220 Because AS64502 receives the more specific prefix from AS64503, 221 traffic from AS64504 to 2001:DB8::/34 follows the path 222 AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are 223 implemented to avoid transporting traffic between AS64504 and 224 AS64503. However, due to the discrepancies of routes between the 225 more and the less specific prefixes, unexpected traffic flows between 226 AS64504 and AS64503 exist in AS64502's network. 228 ____,,................______ 229 _,.---'''' `''---..._ 230 ,-'' AS64505 `-. 231 [ / 232 -.._ __.-' 233 . `'---....______ ______...---'' 234 + |/32 `''''''''''''''' | 235 | |/34 + |/32 | 236 v | v |/34 | 237 | | ^ | 238 | ^ |/32 | |/32 239 | + | + |/34 240 _,,---.:_ _,,---.._ _,,---.._ 241 ,' `. ,' `. ,' `. 242 / AS64504 \ <-+ / AS64502 \ / AS64503 \ 243 | |_________| |________| | 244 | | /32 | |/32 /32| | 245 '. ,' . ,' /34 . ,' 246 `. ,' `. ,' +-> <-+ `. ,' 247 ``---'' ``---'' ``---'' 248 | ^ | 249 ^ |2001:DB8::/32 | |2001:DB8::/32 250 | | + |2001:DB8::/34 251 + | _....---------...._| 252 ,-'AS64501 ``-. 253 /' `. 254 `. _, 255 `-.._ _,,,' 256 `''---------''' 258 Figure 2: Unexpected traffic flows due to local filtering 260 2.2. Remote filtering 262 ISPs can tag the BGP paths that they propagate to neighboring ASes 263 with communities, in order to tweak the propagation behavior of the 264 ASes that handle these paths [on_BGP_communities]. Some ISPs allow 265 their customers to use such communities to let the receiving AS not 266 export the path to some selected neighboring ASes. By combining 267 communities, the prefix could be advertised only to a given peer of 268 the AS providing this feature. A network operator can leverage 269 remote filtering to, for instance, limit the scope of prefixes and 270 hence perform a more granular inbound traffic engineering. 272 Figure 3 illustrates a scenario in which an AS uses BGP communities 273 to command its provider to selectively propagate a more specific 274 prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501 275 originates prefix 2001:DB8::/32, which it advertises to AS64502 and 276 AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501 277 do selective advertisement and only propagate 2001:DB8::/34 over 278 AS64503. AS64503 would normally propagate this prefix to its 279 customers, providers, and peers, including AS64502. 281 Let us consider that AS64501 decides to limit the scope of the more 282 specific prefix. AS64501 can make this decision based on its traffic 283 engineering strategy. To achieve this, AS64501 can tag the more 284 specific prefix with a set of communities that leads AS64503 to only 285 propagate the path to AS64502. 287 ^ \ / ^ ^ \ / ^ 288 | /32 \ / /32 | | /32 \ / /32 | 289 ,-----. ,-----. 290 ,' `. ,' `. 291 / AS64502 \ / AS64503 \ 292 ( )-------------( ) 293 \ / /32 /32 \ / 294 `. ,' -> /34 `. ,' 295 '-----; <- / '-----' 296 \ / 297 ^ \ / ^ 298 | \ / | 299 | \ / | 300 | \ ,-----.' | 2001:DB8::/32 301 | ,' `. | 2001:DB8::/34 302 2001:DB8::/32 +-- / AS64501 \ --+ 303 ( ) 304 \ / 305 `. ,' 306 '-----' 308 Figure 3: Remote triggered filtering 310 2.2.1. Unexpected traffic flows caused by remotely triggered filtering 311 of more specific prefixes 313 Figure 4 expands the scenario from Figure 3 and includes other ASes 314 peering with AS64502 and AS64503. Due to the limitation on the scope 315 performed on the more specific prefix, ASes that are not customers of 316 AS64502 will not receive a path for 2001:DB8::/34. These ASes will 317 forward packets destined to 2001:DB8::/34 according to their routing 318 state for 2001:DB8::/32. Let us assume that AS64505 is such an AS, 319 and that its best path towards 2001:DB8::/32 is through AS64502. 320 Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502. 321 However, in the data-plane of the nodes of AS64502, the longest 322 prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached 323 through AS64503, a settlement-free peer of AS64502. Since AS64505 is 324 not in the customer branch of AS64502, traffic flows between two non- 325 customer ASes in AS64502. 327 ,-----. 328 ,' `. 329 / AS64505 \ 330 ( ) 331 \ / 332 ,`. ,' \ 333 / '-----' \ 334 / ^ ^ \ 335 /32 | | /32 ' 336 ,-----.' + + ,-----. 337 ,' `. ,' `. 338 / AS64502 \ / AS64503 \ 339 ( )-------------( ) 340 \ / /32 /32 \ / 341 `. ,' +-> /34 `. ,' 342 '-----; <-+ / '-----' 343 \ / 344 ^ \ / ^ 345 | \ / | 346 | \ / | 347 | \ ,-----.' | 2001:DB8::/32 348 | ,' `. | 2001:DB8::/34 349 2001:DB8::/32 +--+ / AS64501 \ +--+ 350 ( ) 351 \ / 352 `. ,' 353 '-----' 355 Figure 4: Unexpected traffic flows due to remote triggered filtering 357 3. Techniques to detect unexpected traffic flows caused by filtering of 358 more specific prefixes 360 3.1. Existence of unexpected traffic flows within an AS 362 To detect if unexpected traffic flows are taking place in its 363 network, an ISP can monitor its traffic data to check if it is 364 providing transit between two of its peers, although this policy is 365 configured to not provide such transit. IPFIX (RFC7011 [RFC7011]) is 366 an example of a technology that can be used to export information 367 regarding traffic flows across the network. Traffic information must 368 be analyzed under the perspective of the business relationships with 369 neighboring ASes to detect the flows not fitting the policy. 370 Operators can use collection systems that combine traffic statistics 371 with policy information for this end. Check [PMACCT] for an open 372 source application meeting these requirements. 374 Note that the AS detecting the unexpected traffic flow may simply 375 realize that this policy configuration is broken. The first 376 recommended action upon detection of an unexpected traffic flow is to 377 verify the correctness of the BGP configuration. 379 Once the local configuration is confirmed correct, the operator 380 should check if the unexpected flow arose due to filtering of BGP 381 paths for more-specific prefixes by neighboring ASes. This can be 382 performed in two steps. First, the operator should check whether the 383 neighboring AS originating the unexpected flow is forwarding traffic 384 using a less-specific prefix that is announced to it by the affected 385 network. The second step is to try to infer the reason why the 386 neighboring AS does not use the more specific path for forwarding, 387 i.e., finding why the more specific prefix was filtered. Due to the 388 distributed nature and restricted visibility of the steering of BGP 389 policies, this second step does not identify the origin of the 390 problem with guaranteed accuracy. 392 For the first step, the operator should check if the destination 393 address of the unexpected traffic flow is locally routed as per a 394 more specific prefix only received from non-customer peers. The 395 operator should also check if there are paths to a less specific 396 prefix received from a customer, and hence propagated to peers. If 397 these two situations happen at the same time, the neighboring AS at 398 the entry point of the unexpected flow is routing the traffic based 399 on the less specific prefix, although the ISP is actually forwarding 400 the traffic via non-customer links. 402 For the second step, one can rely on human interaction or looking 403 glasses to find out whether local filtering, remote filtering, or 404 selective propagation was performed on the more specific prefix. No 405 openly available tools that can automatically perform this operation 406 have been identified. 408 3.2. Contribution to the existence of unexpected traffic flows in 409 another AS 411 It can be considered problematic to trigger unexpected traffic flows 412 in another AS. It is thus advisable for an AS to assess the risks of 413 filtering more specific prefixes before implementing them, by 414 obtaining as much information as possible about its surrounding 415 routing environment. 417 There may be justifiable reasons for one ISP to perform filtering; 418 either to enforce established policies or to provide prefix 419 advertisement scoping features to its customers. These can vary from 420 trouble-shooting purposes to business relationship implementations. 421 Restricting the use of these features for the sake of avoiding the 422 creation of unexpected traffic flows is not a practical option. 424 In order to assess the risk of filtering more specific prefixes, the 425 AS would need information on the routing policies and the 426 relationships among external ASes, to detect if its actions could 427 trigger the appearance of unexpected traffic flows. With this 428 information, the operator could detect other ASes receiving the more 429 specific prefix from non-customer ASes, while announcing the less 430 specific prefix to other non-customer ASes. If the filtering of the 431 more specific prefix leads other ASes to send traffic for the more 432 specific prefix to these ASes, an unexpected traffic flow can arise. 433 However, the information required for this operation is difficult to 434 obtain since it is frequently considered confidential. 436 4. Techniques to Traffic Engineer unexpected flows 438 Network Operators can adopt different approaches with respect to 439 unexpected traffic flows. Note that due the complexity of inter- 440 domain routing policies, there is not a single solution that can be 441 applied to all situations. This section provides potential solutions 442 that ISPs must evaluate against each particular case. We classify 443 these actions according to whether they are proactive or reactive. 445 Reactive approaches are those in which the operator tries to detect 446 the situations via monitoring and solve unexpected traffic flows, 447 manually, on a case-by-case basis. 449 Anticipant or preventive approaches are those in which the routing 450 system will not let the unexpected traffic flows actually take place 451 when the scenario arises. 453 We use the scenario depicted in Figure 5 to describe these two kinds 454 of approaches. Since proactive approaches can be complex to 455 implement and can lead to undesired effects, the reactive approach is 456 the more reasonable recommendation to deal with unexpected flows. 458 ____,,................______ 459 _,.---'''' `''---..._ 460 ,-'' AS64505 `-. 461 [ / 462 -.._ __.-' 463 . `'---....______ ______...---'' 464 + |/32 `''''''''''''''' | 465 | |/34 + |/32 | 466 v | v |/34 | 467 | | ^ | 468 | ^ |/32 | |/32 469 | + | + |/34 470 _,,---.:_ _,,---.._ _,,---.._ 471 ,' `. ,' `. ,' `. 472 / AS64504 \ <-+ / AS64502 \ / AS64503 \ 473 | |_________| | | | 474 | | /32 | | | | 475 '. ,' . ,' . ,' 476 `. ,' `. ,' `. ,' 477 ``---'' ``---'' ``---'' 478 | ^ | 479 ^ |2001:DB8::/32 | |2001:DB8::/32 480 | | + |2001:DB8::/34 481 + | _....---------...._| 482 ,-'AS64501 ``-. 483 /' `. 484 `. _, 485 `-.._ _,,,' 486 `''---------''' 488 Figure 5: Traffic Engineering of unexpected traffic flows - Base 489 example 491 4.1. Reactive Traffic Engineering 493 An operator who detects unexpected traffic flows originated by any of 494 the cases described in Section 2 can contact the ASes that are likely 495 to have performed the propagation tweaks, inform them of the 496 situation, and persuade them to change their behavior. 498 If the situation remains, the operator can implement prefix filtering 499 in order to stop the unexpected flows. The operator can decide to 500 perform this action over the session with the operator announcing the 501 more specific prefix or over the session with the neighboring AS from 502 which it is receiving the traffic. Each of these options carry a 503 different repercussion for the affected AS. We briefly describe the 504 two alternatives. 506 o An operator can decide to stop announcing the less specific prefix 507 at the peering session with the neighboring AS from which it is 508 receiving traffic to the more specific prefix. In the example of 509 Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from 510 the eBGP session with AS64504. In this case, traffic heading to 511 the prefix 2001:DB8::/32 from AS64501 would no longer traverse 512 AS64502. AS64502 should evaluate if solving the issues originated 513 by the unexpected traffic flows are worth the loss of this traffic 514 share. 516 o An operator can decide to filter out the more specific prefix at 517 the peering session over which it was received. In the example of 518 Figure 5, AS64502 would filter out the incoming prefix 519 2001:DB8::/34 from the eBGP session with AS64505. As a result, 520 the traffic destined to that /32 would be forwarded by AS64502 521 along its link with AS64501, despite the actions performed by 522 AS64501 to have this traffic coming in through its link with 523 AS64503. However, as AS64502 will no longer know a route to the 524 more specific prefix, it risks losing the traffic share from 525 customers different from AS64501 to that prefix. Furthermore, 526 this action can generate conflicts between AS64502 and AS64501, 527 since AS64502 does not follow the routing information expressed by 528 AS64501 in its BGP announcements. 530 Note that it is possible that the behavior of the neighboring AS 531 causing the unexpected traffic flows violates a contractual agreement 532 between the two networks. 534 4.2. Proactive measures 536 4.2.1. Access lists 538 An operator could install access-lists to prevent unexpected traffic 539 flows from happening in the first place. In the example of Figure 5, 540 AS64502 would install an access-list denying packets matching 541 2001:DB8::/34 associated with the interface connecting to AS64504. 542 As a result, traffic destined to that prefix would be dropped, 543 despite the existence of a valid route towards 2001:DB8::/32. 545 The operational overhead of such a solution is considered high, as 546 the operator would have to constantly adapt these access-lists to 547 accommodate inter-domain routing changes. Moreover, this technique 548 lets packets destined to a valid prefix be dropped while they are 549 sent from a neighboring AS that may not know about the policy 550 conflict, and hence had no means to avoid the creation of unexpected 551 traffic flows. For this reason, this technique can be considered 552 harmful. 554 4.2.2. Neighbor-specific forwarding 556 An operator can technically ensure that traffic destined to a given 557 prefix will be forwarded from an entry point of the network based 558 only on the set of paths that have been advertised over that entry 559 point. 561 As an example, let us analyze the scenario of Figure 5 from the point 562 of view of AS64502. The edge router connecting to the AS64504 563 forwards packets destined to prefix 2001:DB8::/34 towards AS64505. 564 Likewise, it forwards packets destined to prefix 2001:DB8::/32 565 towards AS64501. The router, however, only propagates the path of 566 the less specific prefix (2001:DB8::/32) to AS64504. An operator 567 could implement the necessary techniques to force the edge router to 568 forward packets coming from AS64504 based only on the paths 569 propagated to AS64504. Thus, the edge router would forward packets 570 destined to 2001:DB8::/34 towards AS64501 in which case no unexpected 571 traffic flow would occur. 573 Different techniques could provide this functionality; however, their 574 technical implementation can be complex to design and operate. An 575 operator could, for instance, employ Virtual Routing Forwarding (VRF) 576 tables (RFC4364 [RFC4364]) to store the routes announced to a 577 neighbor and forward traffic exclusively based on those routes. 578 [on_BGP_RS_VPNs] describes the use of such an architecture for 579 Internet routing, and provides a description of its limitations. 581 In such architecture, packets received from a peer would be forwarded 582 solely based on the paths that fit the path propagation policy for 583 that peer, and not based on the global routing table of the router. 584 As a result, a more specific path that would not be propagated to a 585 peer will not be used to forward a packet from that peer, and the 586 unexpected flow will not take place. Packets will be forwarded based 587 on the policy compliant less specific prefix. However, note that an 588 operator must make sure that all their routers could support the 589 potential performance impact of this approach. 591 Note that similarly to the solution described in Section 4.1, this 592 approach could create conflicts between AS64502 and AS64501, since 593 the traffic forwarding performed by AS64502 goes against the policy 594 of AS64501. 596 5. Conclusions 598 This document describes how filtering and selective propagation of 599 more-specific prefixes can potentially create unexpected traffic 600 flows across some ASes. We provided examples of scenarios where 601 these practices lead to unexpected traffic flows, and introduce some 602 techniques for their detection and prevention. Although there are 603 reasonable situations in which ASes could filter more-specific 604 prefixes, network operators are encouraged to implement this type of 605 filters considering the cases described in this document. Operators 606 can implement monitoring systems to detect unexpected traffic flows 607 and react to them according to their own policy. 609 6. Security Considerations 611 It is possible for an AS to use any of the methods described in this 612 document to deliberately reroute traffic flowing through another AS. 613 This document informed on the potential routing security issue, and 614 analyzed ways for operators to defend against it. 616 It must be noted that, at the time of this document, there are no 617 existing or proposed tools to automatically protect against such 618 behavior. Operators can use network monitoring and collection tools 619 to detect unexpected flows and deal with them on a case-by-case 620 basis. 622 7. IANA Considerations 624 This document has no IANA actions. 626 8. Acknowledgments 628 The authors would like to thank Wes George, Jon Mitchell, Bruno 629 Decraene, and Job Snijders for their useful suggestions and comments. 631 9. References 633 9.1. Normative References 635 [RFC4384] Meyer, D., "BGP Communities for Data Collection", RFC 636 4384, February 2006. 638 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 639 1812, June 1995. 641 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 642 the IP Flow Information Export (IPFIX) Protocol for the 643 Exchange of Flow Information", RFC 7011, September 2013. 645 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 646 Networks (VPNs)", RFC 4364, February 2006. 648 9.2. Informative References 650 [on_BGP_communities] 651 Donnet, B. and O. Bonaventure, "On BGP Communities", ACM 652 SIGCOMM Computer Communication Review vol. 38, no. 2, pp. 653 55-59, April 2008. 655 [on_BGP_RS_VPNs] 656 Vanbever, L., Francois, P., Bonaventure, O., and J. 657 Rexford, "Customized BGP Route Selection Using BGP/MPLS 658 VPNs", Cisco Systems, Routing Symposium 659 http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf, 660 October 2009. 662 [INIT7-RIPE63] 663 "INIT7-RIPE63", . 666 [PMACCT] "pmacct project: IP accounting iconoclasm", 667 . 669 Authors' Addresses 671 Camilo Cardona 672 IMDEA Networks/UC3M 673 Avenida del Mar Mediterraneo, 22 674 Leganes 28919 675 Spain 677 Email: juancamilo.cardona@imdea.org 679 Pierre Francois 680 Cisco Systems 681 170 W. Tasman Drive 682 San Jose, CA 95134 683 USA 685 Email: pifranco@cisco.com 687 Paolo Lucente 688 Cisco Systems 689 170 W. Tasman Drive 690 San Jose, CA 95134 691 USA 693 Email: plucente@cisco.com