idnits 2.17.1 draft-cardona-filtering-threats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 52 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2012) is 4225 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-white-grow-overlapping-routes-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Camilo Cardona 3 Internet-Draft Pierre Francois 4 Intended status: Informational IMDEA Networks 5 Expires: March 29, 2013 September 25, 2012 7 Making BGP filtering an habit: Impact on policies 8 draft-cardona-filtering-threats-00 10 Abstract 12 This draft describes potential threats to the Internet routing 13 policies of an autonomous system due to filtering of more specific 14 BGP prefixes by its neighboring domains. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 29, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Filtering overlapping prefixes . . . . . . . . . . . . . . . . 3 52 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Remotely triggered filtering . . . . . . . . . . . . . . . 5 54 3. Uses of more specific prefix filtering that violate 55 policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Violation caused by Local filtering . . . . . . . . . . . 7 57 3.1.1. Initial setup . . . . . . . . . . . . . . . . . . . . 7 58 3.1.2. Violation of Policy - Case 1 . . . . . . . . . . . . . 8 59 3.1.3. Violation of Policy - Case 2 . . . . . . . . . . . . . 9 60 3.2. Violation caused by remotely triggered filtering . . . . . 10 61 3.2.1. Initial setup . . . . . . . . . . . . . . . . . . . . 10 62 3.2.2. Injection of a more specific . . . . . . . . . . . . . 11 63 3.2.3. Limiting the scope of the more specific . . . . . . . 12 64 4. Techniques to detect dataplane-based policy violations . . . . 14 65 4.1. Being the victim of the policy violation . . . . . . . . . 14 66 4.2. Being a contributor to the policy violation . . . . . . . 14 67 5. Techniques to counter policy violations . . . . . . . . . . . 15 68 5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 15 69 5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 16 70 5.2.1. Neighbor-specific forwarding . . . . . . . . . . . . . 16 71 5.2.2. Access lists . . . . . . . . . . . . . . . . . . . . . 16 72 5.2.3. Automatic filtering . . . . . . . . . . . . . . . . . 16 73 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 It is common practice for network operators to propagate overlapping 80 prefixes along with the prefixes that they originate. On the other 81 hand, it can be beneficial for some Autonomous Systems (ASes) to 82 filter overlapping prefixes (such operation needs to be translated 83 into various requirements in order to be automatically performed) 84 DRAFT-WHITE [1]. 86 BGP makes independent, policy driven decisions for the selection of 87 the best path to be used for a given IP prefix. However, in the data 88 plane, the longest prefix match forwarding rule "precedes" the 89 application of such policies. The existence of a prefix p' that is 90 more specific than a prefix p in the Routing Information Base (RIB) 91 will indeed let packets whose destination matches p' be forwarded 92 according to the next hop selected as best for p' (the overlapping 93 prefix). This process takes place by disregarding the policies 94 applied in the control plane for the selection of the best next-hop 95 for p (the covering prefix). When overlapping prefixes are filtered 96 and packets are forwarded according to the covering prefix, the 97 discrepancy in the routing policies applied both covering and 98 overlapping prefixes can lead to a violation of policies of Internet 99 Service Providing (ISPs) still holding a path towards the overlapping 100 prefix. 102 This document presents examples of such potential threats, and 103 discusses solutions to the problem. The objective of this draft is 104 to enable the use of prefix filtering while making the routing 105 community aware of the cases where the effects of filtering might 106 turn to be negative for the business of ISPs. 108 The rest of the document is organized as follows: Section 2 describes 109 some cases in which it is favorable for an AS to filter overlapping 110 prefixes. In Section 3, we provide some scenarios in which the 111 filtering of overlapping prefixes lead to policy violations of other 112 ASes. Section 4 and Section 5 introduce some techniques that ASes 113 can use for, respectively, detect and react to policy violations. 115 2. Filtering overlapping prefixes 117 There are different scenarios where filtering an overlapping prefix 118 is relevant to the operations of an AS. In this section, we 119 illustrate examples of these scenarios. We differentiate cases in 120 which the filtering is performed locally from those where the 121 filtering is triggered remotely, by using BGP communities. These 122 scenarios will be used as a base in Section 3 for describing side 123 effects bound with such practices, notably policy violations in the 124 ASes surrounding the AS applying the procedure. 126 2.1. Local filtering 128 Let us first analyze the scenario depicted in Figure 1. AS1 and AS2 129 are two large autonomous systems spanning a large geographical area 130 and peering in 3 different physical locations. Let AS1 announce 131 prefix 10.0.0.0/22 through the sessions established between the two 132 ASes over all peering links. Additionally, let us define that there 133 is part of AS1's network which exclusively uses prefix 10.0.0.0/24 134 and which is closer to one specific peering point than to others 135 (right peering link). With the purpose of receiving the traffic from 136 AS2 to prefix 10.0.0.0/24 on the right peering link, AS1 could 137 announce the overlapping prefix on this specific peering point. At 138 the time of the establishment of the peering, it can be defined by 139 both ASes that hot potato routing would happen in both directions of 140 traffic. In this scenario, it becomes relevant for AS2 to enforce 141 such practice by detecting the described situations and automatically 142 issue the appropriate filtering. In this case, by implementing these 143 automatic procedures, AS2 would detect and filter prefix 10.0.0.0/24. 145 ___....-----------....___ 146 ,.--' AS2 `--.. 147 ,' `. 148 | | 149 `._ _.' 150 `--..__ _,,.--' 151 . `'''-----------'''' | 152 | | | 153 | | | 154 10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22 155 | ___....-----------....___ |10.0.0.0/24 156 ,.--'AS1 `--.. 157 ,' ...........`. 158 | |10.0.0.0/24 | 159 `._ |........._.' 160 `--..__ _,,.--' 161 `'''-----------'''' 163 Figure 1: Basic scenario local filtering 1 165 There are other cases in which there could exist a need for local 166 filtering. For example, a dual homed AS receiving an overlapping 167 prefix from only one of its providers. Figure 2 depicts a simple 168 example of this case. 170 _..._ 171 ,' `. 172 / AS4 \ 173 | | 174 \ / 175 ,`-...-'. 176 / '. 177 10.0.0.0/22 ,' \ 178 10.0.0.0/24 / \ 10.0.0.0/22 179 ..:_ >..._ 180 ,' `. ,' `. 181 / AS2 \ / AS3 \ 182 | | | | 183 \ / \ / 184 `-...-', `-...-' 185 \ / 186 \ / 187 10.0.0.0/22 \_..._ '10.0.0.0/22 188 10.0.0.0/24,' `. 189 / AS1 \ 190 | | 191 \ / 192 `-...-' 194 Figure 2: Basic scenario local filtering 2 196 In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and 197 AS3. Both AS propagate the prefix to AS4. Additionally, AS1 198 advertises prefix 10.0.0.0/24 to AS3, which subsequently propagates 199 the prefix to AS4. 10.0.0.0/22 is a covering prefix for 10.0.0.0/24. 201 It is possible that AS4 resolves to filter the more specific prefix 202 10.0.0.0/24. One potential motivation could be the economical 203 preference of the path via AS2 over AS3. Another feasible reason is 204 the existence of a technical policy by AS4 of aggregating incoming 205 prefixes longer than /23. 207 The above examples illustrate two of the many motivations to 208 configure routing within an AS with the aim of ignoring more specific 209 routes. Operators have reported applying these filters in a manual 210 fashion INIT7-RIPE63 [2]. The relevance of such practice led to 211 investigate automated filtering procedures (DRAFT-WHITE [1]). 213 2.2. Remotely triggered filtering 215 ISPs can tag the BGP paths that they propagate to neighboring ASes 216 with communities, so as to tweak the propagation behavior of the ASes 217 that handle such propagated paths [on_BGP_communities]. 219 Some ISPs allow their direct and indirect customers to use such 220 communities in order to let the receiving AS not export the path to 221 some selected neighboring AS. By combining communities, the prefix 222 could be advertised only to a given peer of the AS providing this 223 feature. Figure 3 illustrates an example of this case. 225 10.0.0.0/22 ,' \ 226 10.0.0.0/24 / \ 10.0.0.0/22 227 ..:_ >..._ 228 ,' `. ,' `. 229 / AS2 \________ / AS3 \ 230 | |/22 /22| | 231 \ / \ / 232 `-...-', `-...-' 233 \ / 234 \ / 235 10.0.0.0/22 \_..._ '10.0.0.0/22 236 10.0.0.0/24,' `. 237 / AS1 \ 238 | | 239 \ / 240 `-...-' 242 Figure 3: Remote triggered filtering 244 AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic 245 engineering purposes, AS1 could use communities to prevent AS2 from 246 announcing prefix 10.0.0.0/24 to AS3. 248 Such technique is useful for operators to tweak routing decisions in 249 order to align with complex transit policies. We will see in the 250 later sections that by producing the same effect as filtering, they 251 can also lead to policy violations at other, distant, ASes. 253 3. Uses of more specific prefix filtering that violate policies 255 We describe in this section three configuration scenarios which lead 256 to the violation of the policies of an AS. Note that these examples 257 do not capture all the cases where such policy violation can take 258 place. More examples will be provided in the future revisions of 259 this document. 261 3.1. Violation caused by Local filtering 263 In this section we describe cases in which an AS locally filters an 264 overlapping prefix. We show how, depending on the situations of BGP 265 policies, this decision leads to the violation of the policies of 266 neighboring ASes. 268 3.1.1. Initial setup 270 We start by describing the basic scenario of this case in Figure 4. 272 ____,,................______ 273 _,.---'''' `''---..._ 274 ,-'' AS5 `-. 275 [ / 276 -.._ __.-' 277 . `'---....______ ______...---'' 278 |/22 `''''''''''''''' |/22 279 |/24 |/22 |/24 280 | |/24 | 281 | | | 282 | |/22 |/22 283 | |/24 |/24 284 _,,---.:_ _,,---.._ _,,---.._ 285 ,' `. ,' `. ,' `. 286 / AS4 \ / AS2 \ / AS3 \ 287 | |_________| |________| | 288 | | /22 | |/22 /22| | 289 '. ,' /24 . ,'/24 /24 . ,' 290 `. ,' `. ,' `. ,' 291 ``---'' ``---'' ``---'' 292 | | 293 |10.0.0.0/24 |10.0.0.0/24 294 |10.0.0.0/22 |10.0.0.0/22 295 | _....---------...._| 296 ,-'AS1 ``-. 297 /' `. 298 `. _, 299 `-.._ _,,,' 300 `''---------''' 302 Figure 4: Initial Setup Local 304 AS1 is a customer of AS2 and AS3. AS2, AS3 and AS4 are customers of 305 AS5. AS2 is establishing a free peering with AS3 and AS4. AS1 is 306 announcing a covering prefix, 10.0.0.0/22, and an overlapping prefix 307 10.0.0.0/24 to its providers. In the initial setup, AS2 and AS3 will 308 announce the two prefixes to their peers and transit providers. AS4 309 receives both prefixes from its peer (AS2) and transit provider 310 (AS5). 312 3.1.2. Violation of Policy - Case 1 314 In the next scenarios, we show that if AS4 filters the incoming 315 overlapping prefix from AS5, there is a situation in which the 316 policies of other ASes are violated. 318 ____,,................______ 319 _,.---'''' `''---..._ 320 ,-'' AS5 `-. 321 [ / 322 -.._ __.-' 323 . `'---....______ ______...---'' 324 |/22 `''''''''''''''' |/22 325 |/24 |/22 | 326 | |/24 | 327 | | | 328 | |/22 |/22 329 | | |/24 330 _,,---.:_ _,,---.._ _,,---.._ 331 ,' `. ,' `. ,' `. 332 / AS4 \ / AS2 \ / AS3 \ 333 | |_________| |________| | 334 | | /22 | |/22 /22| | 335 '. ,' . ,' /24 . ,' 336 `. ,' `. ,' `. ,' 337 ``---'' ``---'' ``---'' 338 | | 339 | |10.0.0.0/24 340 |10.0.0.0/22 |10.0.0.0/22 341 | _,,..---------...._| 342 ,-'AS1 ``-. 343 /' `. 344 `. _, 345 `-.._ _,,,' 346 `''---------''' 348 Figure 5: Initial Setup Local 350 Let us assume the scenario illustrated in Figure 5. For this case, 351 AS1 only propagates the overlapping prefix to AS3. AS4 receives the 352 overlapping prefix only from its traffic provider, AS5. 354 The described example places AS4 in a situation in which it would be 355 favorable for it to filter the announcement of prefix 10.0.0.0/24 356 from AS5. Subsequently, traffic originating from AS4 to prefix 357 10.0.0.0/24 is forwarded to AS2. As AS2 receives the more specific 358 prefix from AS3, traffic originating from AS4 and heading to prefix 359 10.0.0.0/24 follows the path AS4-AS2-AS3-AS1. This violates the 360 policy of AS2, since it forwards traffic from a peer to a non- 361 customer neighbor. 363 3.1.3. Violation of Policy - Case 2 365 ____,,................______ 366 _,.---'''' `''---..._ 367 ,-'' AS5 `-. 368 [ / 369 -.._ __.-' 370 . `'---....______ ______...---'' 371 |/22 `''''''''''''''' |/22 372 |/24 |/22 | 373 | |/24 | 374 | | | 375 | |/22 |/22 376 | | |/24 377 _,,---.:_ _,,---.._ _,,---.._ 378 ,' `. ,' `. ,' `. 379 / AS4 \ / AS2 \ / AS3 \ 380 | |_________| | | | 381 | | /22 | | | | 382 '. ,' . ,' . ,' 383 `. ,' `. ,' `. ,' 384 ``---'' ``---'' ``---'' 385 | | 386 | |10.0.0.0/24 387 |10.0.0.0/22 |10.0.0.0/22 388 _;,..---------...._| 389 ,-'AS1 ``-. 390 /' `. 391 `. _, 392 `-.._ _,,,' 393 `''---------''' 395 Figure 6: Initial Setup Local 397 Let us assume a second case where AS2 and AS3 are not peering and AS1 398 only propagates the overlapping prefix to AS3. AS4 receives the 399 overlapping prefix only from its traffic provider, AS5. This case is 400 illustrated in Figure 6. 402 Similar to the scenario described in Section 3.1.2, AS4 is in a 403 situation in which it would be favorable to filter the announcement 404 of prefix 10.0.0.0/24 from AS5. Subsequently, traffic originating 405 from AS4 to prefix 10.0.0.0/24 is forwarded to AS2. Traffic 406 originating in AS4 and heading for prefix 10.0.0.0/24 would follow 407 the path AS4-AS2-AS5-AS3-AS1. This path violates the policy of AS2, 408 as this AS is forwarding traffic from a peer to a transit network. 410 3.2. Violation caused by remotely triggered filtering 412 We present a configuration scenario in which an AS, using the 413 mechanism described in Section 2.2, informs its provider to 414 selectively announce a covering prefix, leading to the violation of a 415 policy of another AS. 417 3.2.1. Initial setup 419 Let AS_cust be a customer AS of AS A and AS B. It owns 10.0.0.0/22, 420 which it advertises through AS A and AS B. Additionally, AS A and AS 421 B are peers. 423 Both AS A and AS B select their customer path as best, and propagate 424 that path to their customers, providers, and peers. 426 Some remote ASes will route traffic destined to 10.0.0.0 through (... 427 A Cust 10.0.0.0/24) while some others will route traffic along (... 428 B Cust 10.0.0.0/24). 430 \ / \ / 431 /22 \ //22 /22 \ //22 432 ,-----. ,-----. 433 ,' `. ,' `. 434 / A \ /22 / B \ 435 ( )-------------( ) 436 \ / /22 \ / 437 `. ,' `. ,' 438 '-----; / '-----' 439 \ / 440 \ / 441 10.0.0.0/22\ /10.0.0.0/22 442 \ / 443 \ ,-----.' 444 ,' `. 445 / Cust \ 446 ( ) 447 \ / 448 `. ,' 449 '-----' 451 Figure 7: Example scenario 453 3.2.2. Injection of a more specific 455 Let AS_cust advertise 10.0.0.0/24 over AS B only. AS B propagates 456 this prefix to its customers, provider and peers, including AS A. 458 From AS A's point of view, such a path is a "peer path", so that this 459 path will only be advertised to its customers. 461 All ASes that are not in the customer branch of AS A will receive a 462 path to the /24 that contains AS B, and not AS A, as AS A has not 463 propagated the prefix to other ASes than its customers. 465 The ASes that are in the customer branch of AS A will receive a path 466 to the /24 that contains AS B and AS A, as AS A has propagated that 467 path to its customers. Some multi-homed customers of ISP A may also 468 receive a path through ISP B, but not through ISP A, from other 469 peering or provider links. 471 \ / /22\ //22 472 /22 \ //22 /24 \ / /24 473 ,-----. ,-----. 474 ,' `. /22 ,' `. 475 / A \ /24 / B \ 476 ( /22:Cust )-------------( /22:Cust ) 477 \ /24:B / /22 \ /24:Cust / 478 /22 /`. ,' `. ,' 479 /24/ '-----; / '-----' 480 / \ / 481 ,---./ \ / 482 / \ 10.0.0.0/22\ /10.0.0.0/22 483 |Cust_2) \ / 10.0.0.0/24 484 \ / \ ,-----.' 485 `---' ,' `. 486 / Cust \ 487 ( ) 488 \ / 489 `. ,' 490 '-----' 492 Figure 8: More Specific Injection 494 Any remote AS that is not lying in the customer branch of A, will 495 receive a path for 10.0.0.0/24 through AS B and not through AS A. 497 Routing is consistent with usual Internet Routing Policies here, as 498 AS A may only receive traffic destined to 10.0.0.0/24 from its 499 customers, which it forwards to its peer AS B. AS B may receive 500 traffic destined to 10.0.0.0/24 from its customers, providers, and 501 peers, which it directly forwards to its customer AS Cust. 503 3.2.3. Limiting the scope of the more specific 505 Now, let us assume that 10.0.0.0/24, which is propagated by AS_Cust 506 to AS B, is tagged so as to have AS B only propagate that path to AS 507 A, using the techniques described in Section 2.2. 509 ,-------. 510 ,' `. 511 / AS_Src \ 512 ( /22:A ) 513 \ / 514 `. ,' 515 '-------' \ / \ / 516 /22 \ //22 /22 \ //22 517 ,-----. ,-----. 518 ,' `. /22 ,' `. 519 / A \ /24 / B \ 520 ( /22:Cust )-------------( /22:Cust ) 521 \ /24:B / /22 \ /24:Cust / 522 /22 /`. ,' `. ,' 523 /24/ '-----; / '-----' 524 / \ / 525 ,---./ \ / 526 / \ 10.0.0.0/22\ /10.0.0.0/22 527 (Cust_2 ) \ / 10.0.0.0/24 528 \ / \ ,-----.' 529 `---' ,' `. 530 / Cust \ 531 ( ) 532 \ / 533 `. ,' 534 '-----' 536 Figure 9: More Specific Injection 538 From AS A's point of view, such a path is a "peer path", so that this 539 path will only be advertised by AS A to its customers. 541 All the ASes that are not in the customer branch of AS A nor in the 542 customer branch of AS B will NOT receive a path to 10.0.0.0/24. 544 All these ASes will forward packets destined to 10.0.0.0/24 according 545 to their routing state for 10.0.0.0/22. 547 Let us assume that AS_Src is such an AS, and that its best path 548 towards 10.0.0.0/22 is through AS A. In that case, packets sent 549 towards 10.0.0.1 by AS_Src will eventually reach AS A. However, in 550 the dataplane of the nodes of AS A, the longest prefix match for 551 10.0.0.0 is 10.0.0.0/24, which is reached through AS B, a peer of AS 552 A. 554 As AS_Src is by definition not in the customer branch of AS A, we are 555 in a situation such that AS A is forwarding non customer originated 556 traffic along peering links, which violates its policies. 558 If the path towards 10.0.0.0/24 is propagated by B to its customers, 559 the traffic originated by ASes in the customer branch of AS A will 560 not follow policy-violating data-plane paths as the forwarding of 561 traffic towards these destinations will always be based on FIB 562 entries for 10.0.0.0/24. However, policy-violation can still take 563 place for the traffic originated from all ASes that are neither in 564 the customer branch of A nor in the customer branch of B. 566 4. Techniques to detect dataplane-based policy violations 568 We differentiate the techniques available for detecting policy 569 violations from the cases in which the interested AS is the victim or 570 contributor of such operations. 572 4.1. Being the victim of the policy violation 574 To detect that its policies have been violated, one ISP can monitor 575 its NetFlow data so as to see if flows entering the ISP network 576 through a non-customer link is being forwarded to a non-customer 577 nexthop. 579 Detecting such a violation can be done by looking at BGP data to see 580 whether there exists in the RIB a prefix P/p' more specific than P/p 581 such that the nexthop for P/p' is through a peer (or a provider) 582 while P/p is routed through a customer. For each such couple of 583 prefixes, direct communication or looking glasses can be used in 584 order to check whether non-customer neighboring ASes are propagating 585 a path towards P/p (and not towards P/p') to their own customers, 586 peers, or providers. This should trigger a warning as this would 587 mean that ASes in the surrounding area of the current AS are 588 forwarding packets based on the routing entry for the less specific 589 prefix only. 591 4.2. Being a contributor to the policy violation 593 It can be considered as problematic to be a contributor of the policy 594 violation as it appears as an abuse of other's network resources. 596 There may be justifiable reasons for one ISP to perform filtering, 597 either to enforce establishing policies or to provide prefix 598 advertisement scoping features to its customers. These can vary from 599 trouble-shooting purposes to business relationships implementations. 600 Restricting such features for the sake of avoiding contributing to 601 potential policy violations in a peer's network is a bad option. 603 Netflow data does not help an ISP to detect that it is acting as a 604 contributor of the policy violation. It is thus advisable to obtain 605 as much information as possible of the Internet environment of the AS 606 and assessing the risks of filtering of overlapping prefixes before 607 implementing them. 609 Monitoring the manipulation of the communities that implement the 610 scoping of prefixes in one's network is recommended to the ISPs which 611 provide these features. The monitored behavior should then be faced 612 against their terms of use. 614 5. Techniques to counter policy violations 616 Network Operators can adopt different approaches with respect to 617 policy violation. We classify these actions according to whether 618 they are anticipant or reactive. 620 Reactive approaches are those in which the operator tries to detect 621 the situations and solves the policy violation through other means 622 than using the routing system. 624 Anticipant or preventive approaches are those in which the routing 625 system will not let the policy violation actually take place when the 626 configuration scenario is set up. 628 5.1. Reactive counter-measures 630 An operator who detects that its policies have been violated can 631 contact the ASes that are likely to have performed the propagation 632 tweaks so as to have them change their behavior. 634 An operator can account the amount of traffic that has been subject 635 to policy violation, and charge the peer that received the policy- 636 violating traffic. That is, the operator can claim that it has been 637 a provider of that peer for that part of the traffic that transited 638 between the two ASes. 640 An operator can decide to filter-out the concerned more specific 641 prefix at the peering session over which it was received. In the 642 example of Figure 9, AS A would filter out 10.0.0.0/24 in its eBGP 643 in-filter associated with the eBGP session with AS B. As a result, 644 the traffic destined to that /24 would be forwarded by AS A along its 645 link with AS_Cust, despite the actions performed by AS_Cust to have 646 this traffic coming in through it link with AS B. 648 5.2. Anticipant counter-measures 650 5.2.1. Neighbor-specific forwarding 652 An operator can technically ensure that the traffic destined to a 653 given prefix will be forwarded from an entry point of its AS, only on 654 the basis of the set of paths that have been advertised over that 655 entry point. 657 5.2.2. Access lists 659 An operator can configure its routers so as to have them dynamically 660 install an access-list made of the prefixes towards which the 661 forwarding of traffic from that interface would lead to a policy 662 violation. Note that this technique actually lets packets destined 663 to a valid prefix be dropped while they are sent from a neighboring 664 AS that cannot know about the policy violation and hence had no means 665 to avoid the policy violation. 667 In the example of Figure 9, AS A would install an access-list denying 668 packets matching 10.0.0.0/24 associated with the interface connecting 669 AS_Src. As a result, the traffic destined to that /24 would be 670 dropped, despite the existence of a non policy-violating route 671 towards 10.0.0.0/22. 673 5.2.3. Automatic filtering 675 As described in Section 3, filtering of overlapping prefixes can in 676 some scenarios lead to policy violations. Nevertheless, depending on 677 the autonomous system implementing such practice, this operation can 678 in fact prevent these cases. This can be illustrated using the 679 example described in Section 3.1.3: In Figure 6, if AS2 or AS3 filter 680 prefix 10.0.0.0/24, there would be no policy violation for AS2. 682 6. Conclusions 684 In this document we described potential threats to policy violation 685 of autonomous systems caused by the filtering of overlapping prefixes 686 by external networks. We provide examples of scenarios of policy 687 violations caused by these practices and introduce some techniques 688 for their detection and counter. We observe that there are 689 reasonable situations in which ASes could filter overlapping 690 prefixes, however, we encourage that network operators implement this 691 type of filters only after considering such threats. 693 7. References 695 [on_BGP_communities] 696 Donnet, B. and O. Bonaventure, "On BGP Communities", ACM 697 SIGCOMM Computer Communication Review vol. 38, no. 2, pp. 698 55-59, April 2008. 700 [1] 703 [2] 706 Authors' Addresses 708 Juan Camilo Cardona 709 IMDEA Networks 710 Avenida del Mar Mediterraneo 711 Leganes 28919 712 Spain 714 Email: juancamilo.cardona@imdea.org 716 Pierre Francois 717 IMDEA Networks 718 Avenida del Mar Mediterraneo 719 Leganes 28919 720 Spain 722 Email: pierre.francois@imdea.org