idnits 2.17.1 draft-ietf-grow-filtering-threats-06.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 (June 9, 2015) is 3243 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: December 11, 2015 IMDEA Networks 6 Paolo Lucente 7 Cisco Systems 8 June 9, 2015 10 Impact of BGP filtering on Inter-Domain Routing Policies 11 draft-ietf-grow-filtering-threats-06 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 December 11, 2015. 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 traffic 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Informative References . . . . . . . . . . . . . . . . . 14 80 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 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 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 more specific 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 more specific prefixes and 101 forwards packets according to the less specific prefix, the 102 discrepancy in the routing policies applied to the less and the more 103 specific prefixes can create unexpected traffic flows that infringe 104 the policies of other ASes, still holding a path towards the more 105 specific prefix. 107 The objective of this draft is to shed light on possible side effects 108 associated with more specific prefix filtering. This document 109 presents examples of such side effects and discusses approaches 110 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, detect and react to unexpected traffic flows. We 117 conclude 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 We re-use the definitions of customer-transit peering and settlement- 129 free peering of RFC4384 [2]. 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 Local filtering can be motivated by different reasons, such as: (1) 163 Traffic engineering, where an AS wants to control its local outbound 164 traffic distribution using only the policy applied to the less 165 specific prefix. Such a practice was notably documented in [3] (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 in which one AS is motivated to 174 perform local filtering due to outbound traffic engineering. The 175 figure depicts AS64504, and two of its neighboring ASes, AS64502, and 176 AS64505. AS64504 has a settlement-free peering with AS64502 and is a 177 customer of AS64505. AS64504 receives from AS64505 prefixes 178 2001:DB8::/32 and 2001:DB8::/34, a less specific and a more specific 179 prefix, respectively. AS64504 receives only 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 the filter is applied, traffic to the more specific prefix will 205 be sent 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 [1]. Some ISPs allow their customers to 266 use such communities to let the receiving AS not export the path to 267 some selected neighboring ASes. By combining communities, the prefix 268 could be advertised only to a given peer of the AS providing this 269 feature. Remote filtering can be leveraged by an AS to, for 270 instance, limit the scope of prefixes and hence perform a more 271 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 AS 315 peering with ASes 64502 and 64503. Due to the limitation on the 316 scope performed on the more specific prefix, ASes that are not 317 customers of AS64502 will not receive a path for 2001:DB8::/34. 318 These ASes will forward packets destined to 2001:DB8::/34 according 319 to their routing state for 2001:DB8::/32. Let us assume that AS64505 320 is such an AS, and that its best path towards 2001:DB8::/32 is 321 through AS64502. Packets sent towards 2001:DB8::1 by AS64505 will 322 reach AS64502. However, in the data-plane of the nodes of AS64502, 323 the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is 324 reached through AS64503, a settlement-free peer of AS64502. Since 325 AS64505 is not in the customer branch of AS64502, we are in a 326 situation in which traffic flows between non-customer ASes take place 327 in AS64502. 329 ,-----. 330 ,' `. ------- Connections to other ASes 331 / AS64505 \ /32 332 ( ) <-+ 333 \ / 334 `. ,' 335 '-----' 336 ^ \ / ^ ^ \ / ^ 337 | /32 \ / /32 | | /32 \ / /32 | 338 + ,-----. + + ,-----. + 339 ,' `. ,' `. 340 / AS64502 \ / AS64503 \ 341 ( )-------------( ) 342 ,-----. \ / /32 /32 \ / 343 ,' `.---------`. ,' +-> /34 `. ,' 344 / AS64504 \ /32 '-----; <-+ / '-----' 345 ( ) /34 \ / 346 \ / <-+ ^ \ / ^ 347 `. ,' | \ / | 348 '-----; | \ / | 349 | \ ,-----.' | 2001:DB8::/32 350 | ,' `. | 2001:DB8::/34 351 2001:DB8::/32 +--+ / AS64501 \ +--+ 352 ( ) 353 \ / 354 `. ,' 355 '-----' 357 Figure 4: Unexpected traffic flows due to remote triggered filtering 359 3. Techniques to detect unexpected traffic flows caused by filtering of 360 more specific prefixes 362 3.1. Existence of unexpected traffic flows within an AS 364 To detect if unexpected traffic flows are taking place in its 365 network, an ISP can monitor its traffic data to check if it is 366 providing transit between two of its peers, although his policy is 367 configured to not provide such transit. IPFIX (RFC7011 [3]) is an 368 example of a technology that can be used to export information 369 regarding traffic flows across the network. Traffic information must 370 be analyzed under the perspective of the business relationships with 371 neighboring ASes. Open source tools such as [4] can be used to this 372 end. 374 Note that the AS detecting the unexpected traffic flow may simply 375 realize that his 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 it has been assessed that the local configuration is correct, 380 the operator should check if the unexpected flow arose due to 381 filtering of BGP paths for more-specific prefixes by neighboring 382 ASes. This can be performed in two steps. First, the operator 383 should check whether the neighboring AS originating the unexpected 384 flow is forwarding traffic using a less-specific prefix that is 385 announced to it by the affected network. The second step is to try 386 to infer the reason why the neighboring AS does not use the more- 387 specific path for forwarding, i.e., finding why the more-specific 388 prefix was filtered. We note that due to the distributed nature and 389 restricted visibility of the steering of BGP policies, this second 390 step is deemed to not identify the origin of the problem with 391 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, human interaction or looking glasses can be used 404 in order to find out whether local filtering, remote filtering, or 405 selective propagation was performed on the more specific prefix. We 406 are not aware, at the time of this writing, of any openly available 407 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 be causing unexpected traffic 413 flows in other ASes. It is thus advisable for an AS to assess the 414 risks of filtering more specific prefixes before implementing them by 415 obtaining as much data 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 traffic 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. We provide potential solutions that ISPs 445 must evaluate against each particular case. We classify these 446 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. Based on our analysis, we observe that proactive 458 approaches can be complex to implement and can lead to undesired 459 effects. Therefore, we conclude that the reactive approach is the 460 more reasonable 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 describe briefly 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 It is possible that the behavior of the neighboring AS causing the 535 unexpected traffic flows opposes the peering agreement. In this 536 case, an operator could account the amount of traffic that has been 537 subject to the unexpected flows, using traffic measurement protocols 538 such as IPFIX, and charge the peer for that traffic. That is, the 539 operator can claim that it has been a provider of that peer for the 540 traffic that transited between the two ASes. 542 4.2. Proactive measures 544 4.2.1. Access lists 546 An operator could install access-lists to prevent unexpected traffic 547 flows from happening in the first place. In the example of Figure 5, 548 AS64502 would install an access-list denying packets matching 549 2001:DB8::/34 associated with the interface connecting to AS64504. 550 As a result, traffic destined to that prefix would be dropped, 551 despite the existence of a valid route towards 2001:DB8::/32. 553 The operational overhead of such a solution is considered high, as 554 the operator would have to constantly adapt these access-lists to 555 accommodate inter-domain routing changes. Moreover, this technique 556 lets packets destined to a valid prefix be dropped while they are 557 sent from a neighboring AS that may not know about the policy 558 conflict, and hence had no means to avoid the creation of unexpected 559 traffic flows. For this reason, this technique can be considered 560 harmful and is thus not recommended for implementation. 562 4.2.2. Neighbor-specific forwarding 564 An operator can technically ensure that traffic destined to a given 565 prefix will be forwarded from an entry point of the network based 566 only on the set of paths that have been advertised over that entry 567 point. 569 As an example, let us analyze the scenario of Figure 5 from the point 570 of view of AS64502. The edge router connecting to the AS64504 571 forwards packets destined to prefix 2001:DB8::/34 towards AS64505. 572 Likewise, it forwards packets destined to prefix 2001:DB8::/32 573 towards AS64501. The router, however, only propagates the path of 574 the less specific prefix (2001:DB8::/32) to AS64504. An operator 575 could implement the necessary techniques to force the edge router to 576 forward packets coming from AS64504 based only on the paths 577 propagated to AS64504. Thus, the edge router would forward packets 578 destined to 2001:DB8::/34 towards AS64501 in which case no unexpected 579 traffic flow would occur. 581 Different techniques could provide this functionality; however, their 582 technical implementation can be complex to design and operate. An 583 operator could, for instance, employ Virtual Routing Forwarding (VRF) 584 tables (RFC4364 [4]) to store the routes announced to a neighbor and 585 forward traffic exclusively based on those routes. [2] describes the 586 use of such an architecture for Internet routing, and provides a 587 description of its limitations. 589 In such architecture, packets received from a peer would be forwarded 590 solely based on the paths that fit the path propagation policy for 591 that peer, and not based on the global routing table of the router. 592 As a result, a more specific path that would not be propagated to a 593 peer will not be used to forward a packet from that peer, and the 594 unexpected flow will not take place. Packets will be forwarded based 595 on the policy compliant less specific prefix. However, note that an 596 operator must make sure that all their routers could support the 597 potential performance impact of this approach. 599 Note that similarly to the solution described in Section 4.1, this 600 approach could create conflicts between AS64502 and AS64501, since 601 the traffic forwarding performed by AS64502 goes against the policy 602 of AS64501. 604 5. Conclusions 606 In this document, we described how the filtering of more specific 607 prefixes can potentially create unexpected traffic flows in remote 608 ASes. We provided examples of scenarios in which unexpected traffic 609 flows are caused by these practices and introduce some techniques for 610 their detection and prevention. Analyzing the different options for 611 dealing with this kind of problems, we recommend ASes to implement 612 monitoring systems that can detect them and react to them according 613 to the specific situation. Although we observe that there are 614 reasonable situations in which ASes could filter more specific 615 prefixes, we encourage network operators to implement this type of 616 filters considering the cases described in this document. 618 6. Security Considerations 620 It is possible for an AS to use any of the methods described in this 621 document to deliberately reroute traffic flowing through another AS. 622 The objective of this document is to inform on this potential routing 623 security issue, and analyse ways for operators to defend against 624 them. 626 It must be noted that, at the time of this document, there are no 627 existing or proposed tools to automatically protect against such 628 behavior. Network monitoring allowing for the detection of 629 unexpected traffic flows exist, but automated configuration changes 630 to solve the problem do not. 632 7. IANA Considerations 634 This document has no IANA actions. 636 8. Acknowledgments 638 The authors would like to thank Wes George, Jon Mitchell, and Bruno 639 Decraene for their useful suggestions and comments. 641 9. References 643 9.1. Informative References 645 [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM 646 SIGCOMM Computer Communication Review vol. 38, no. 2, pp. 647 55-59, April 2008. 649 [2] Vanbever, L., Francois, P., Bonaventure, O., and J. 650 Rexford, "Customized BGP Route Selection Using BGP/MPLS 651 VPNs", Cisco Systems, Routing Symposium 652 http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf, 653 October 2009. 655 [3] "INIT7-RIPE63", . 658 [4] "pmacct project: IP accounting iconoclasm", 659 . 661 9.2. URIs 663 [1] http://www.ietf.org/rfc/rfc1812.txt 665 [2] http://www.ietf.org/rfc/rfc4384.txt 667 [3] http://www.ietf.org/rfc/rfc7011.txt 669 [4] http://www.ietf.org/rfc/rfc4364.txt 671 Authors' Addresses 673 Camilo Cardona 674 IMDEA Networks/UC3M 675 Avenida del Mar Mediterraneo, 22 676 Leganes 28919 677 Spain 679 Email: juancamilo.cardona@imdea.org 681 Pierre Francois 682 IMDEA Networks 683 Avenida del Mar Mediterraneo, 22 684 Leganes 28919 685 Spain 687 Email: pierre.francois@imdea.org 688 Paolo Lucente 689 Cisco Systems 690 170 W. Tasman Drive 691 San Jose, CA 95134 692 USA 694 Email: plucente@cisco.com