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