--- 1/draft-ietf-grow-filtering-threats-01.txt 2014-02-13 09:14:34.218079590 -0800 +++ 2/draft-ietf-grow-filtering-threats-02.txt 2014-02-13 09:14:34.266080760 -0800 @@ -1,104 +1,108 @@ Network Working Group Camilo Cardona Internet-Draft IMDEA Networks/UC3M Intended status: Informational Pierre Francois -Expires: April 21, 2014 IMDEA Networks - October 18, 2013 +Expires: August 17, 2014 IMDEA Networks + Paolo Lucente + Cisco Systems + February 13, 2014 Making BGP filtering a habit: Impact on policies - draft-ietf-grow-filtering-threats-01 + draft-ietf-grow-filtering-threats-02 Abstract Network operators define their BGP policies based on the business relationships that they maintain with their peers. By limiting the propagation of BGP prefixes, an autonomous system avoids the existence of flows between BGP peers that do not provide any economical gain. This draft describes how unexpected traffic flows can emerge in autonomous systems due to the filtering of overlapping BGP prefixes by neighboring domains. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 21, 2014. + This Internet-Draft will expire on August 17, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Filtering overlapping prefixes . . . . . . . . . . . . . . . . 3 - 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Remotely triggered filtering . . . . . . . . . . . . . . . 5 - 3. Uses of overlapping prefix filtering that create - unexpected traffic flows . . . . . . . . . . . . . . . . . . . 6 - 3.1. Unexpected traffic Flows . . . . . . . . . . . . . . . . . 7 - 3.1.1. Unexpected traffic flows caused by local filtering - of overlapping prefixes . . . . . . . . . . . . . . . 8 - 3.1.2. Unexpected traffic flows caused by remotely - triggered filtering of overlapping prefixes . . . . . 11 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Filtering overlapping prefixes . . . . . . . . . . . . . . . 3 + 2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Remotely triggered filtering . . . . . . . . . . . . . . 6 + 3. Uses of overlapping prefix filtering that create unexpected + traffic flows . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Unexpected traffic Flows . . . . . . . . . . . . . . . . 7 + 3.1.1. Unexpected traffic flows caused by local filtering of + overlapping prefixes . . . . . . . . . . . . . . . . 8 + 3.1.2. Unexpected traffic flows caused by remotely triggered + filtering of overlapping prefixes . . . . . . . . . . 12 4. Techniques to detect unexpected traffic flows caused by - filtering of overlapping prefixes . . . . . . . . . . . . . . 14 - 4.1. Being the 'victim' of unexpected traffic flows . . . . . . 15 + filtering of overlapping prefixes . . . . . . . . . . . . . . 15 + 4.1. Being the 'victim' of unexpected traffic flows . . . . . 15 4.2. Being a contributor to the existence of unexpected traffic flows in other networks . . . . . . . . . . . . . 15 5. Techniques to counter unexpected traffic flows due to the filtering of overlapping prefixes . . . . . . . . . . . . . . 16 5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 17 5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 18 - 5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . . 18 - 5.2.2. Automatic overlapping prefix filtering . . . . . . . . 19 - 5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . . 19 + 5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 18 + 5.2.2. Automatic overlapping prefix filtering . . . . . . . 19 + 5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . 19 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. References . . . . . . . . . . . . . . . . . . . . . . . 0 + 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction It is common practice for network operators to propagate overlapping prefixes along with the prefixes that they originate. It is also possible for some Autonomous Systems (ASes) to apply different policies to the overlapping (more specific) and the covering (less specific) prefix. Some ASes can even benefit from filtering the overlapping prefixes. BGP makes independent, policy driven decisions for the selection of the best path to be used for a given IP prefix. However, routers must forward packets using the longest-prefix-match rule, which - "precedes" any BGP policy (RFC1812 [4]). Indeed, the existence of a + "precedes" any BGP policy (RFC1812 [1]). Indeed, the existence of a prefix p that is more specific than a prefix p' in the Forwarding Information Base (FIB) will let packets whose destination matches p be forwarded according to the next hop selected as best for p (the overlapping prefix). This process takes place by disregarding the policies applied in the control plane for the selection of the best next-hop for p' (the covering prefix). When an Autonomous System filters overlapping prefixes and forwards packets according to the covering prefix, the discrepancy in the routing policies applied to covering and overlapping prefixes can create unexpected traffic flows that infringe the policies of other ASes still holding a path towards @@ -207,21 +211,21 @@ It is possible that AS4 resolves to filter the more specific prefix 10.0.0.0/24. One potential motivation could be the economical preference of the path via AS2 over AS3. Another feasible reason is the existence of a technical policy by AS4 of aggregating incoming prefixes longer than /23. The above examples illustrate two of the many motivations to configure routing within an AS with the aim of ignoring more specific prefixes. Operators have reported applying these filters in a manual fashion [3]. The relevance of such practice led to investigate - automated filtering procedures in I-D.WHITE [5]. + automated filtering procedures in I-D.WHITE [2]. 2.2. Remotely triggered filtering ISPs can tag the BGP paths that they propagate to neighboring ASes with communities, in order to tweak the propagation behavior of the ASes that handle these paths [1]. Some ISPs allow their direct and indirect customers to use such communities to let the receiving AS not export the path to some selected neighboring AS. By combining communities, the prefix could @@ -266,21 +270,21 @@ 3.1. Unexpected traffic Flows The BGP policy of an Internet Service provider includes all actions performed over its originated routes and the routes received externally. One important part of the BGP policy is the selection of the routes that are propagated to each neighboring AS. One of the goals of these policies is to allow ISPs to avoid transporting traffic between two ASes without economical gain. For instance, ISPs typically propagate to their peers only routes coming from its - customers (RFC4384 [6]). We briefly illustrate this operation in + customers (RFC4384 [3]). We briefly illustrate this operation in Figure 4. In the figure, AS2 is establishing a settlement free peering with AS1 and AS3. AS2 receives prefix P3/p3, from AS3. AS2, however, is not interested in transporting traffic from AS1 to AS3, therefore it does not propagate the prefix to AS1. In the figure, we also show a customer of AS2, AS4, which is announcing prefix P4/p4. AS2 propagates this prefix to AS1. ,-----. ,-----. ,-----. ,' `. ,' `. ,' `. / AS1 \ / AS2 \ / AS3 \ @@ -402,30 +406,29 @@ Figure 6: Unexpected traffic flows by local filtering - Case 1 Let us assume the scenario illustrated in Figure 6. For this case, AS1 only propagates the overlapping prefix to AS3. AS4 receives the overlapping prefix only from its transit provider, AS5. AS4 now is in a situation in which it would be favorable for it to filter the announcement of prefix 10.0.0.0/24 from AS5. Subsequently, traffic from AS4 to prefix 10.0.0.0/24 is forwarded towards AS2. Because AS2 receives the more specific prefix from AS3, - traffic from AS4 to prefix 10.0.0.0/24 follows the path AS4-AS2-AS3- - AS1. AS2's BGP policies are implemented to avoid using itself to - exchange traffic between AS4 and AS3. However, due to the + traffic from AS4 to prefix 10.0.0.0/24 follows the path + AS4-AS2-AS3-AS1. AS2's BGP policies are implemented to avoid using + itself to exchange traffic between AS4 and AS3. However, due to the discrepancies of routes from the overlapping and covering prefixes, unexpected traffic flows between AS4 and AS3 still exist on AS2's network. This situation is economically detrimental for AS2, since it forwards traffic from a peer to a non-customer neighbor. 3.1.1.3. Unexpected traffic flows by local filtering - Case 2 - ____,,................______ _,.---'''' `''---..._ ,-'' AS5 `-. [ / -.._ __.-' . `'---....______ ______...---'' |/22 `''''''''''''''' | |/24 |/22 | | |/24 | | | | @@ -765,27 +769,27 @@ prefix be dropped while they are sent from a neighboring AS that cannot know about policy conflicts and hence had no means to avoid the creation of unexpected traffic flows. 5.2.2. Automatic overlapping prefix filtering As described in Section 3, filtering of overlapping prefixes can in some scenarios lead to unexpected traffic flows. Nevertheless, depending on the autonomous system implementing such practice, this operation can prevent these cases. This can be illustrated using the - example described in Figure 11: if AS2 or AS3 filter prefix - 10.0.0.0/24, there would be no unexpected traffic flow in AS2. - Nevertheless, as described in Section 5.1, the filtering of - overlapping prefixes can generate conflicts between AS1 and AS2, - since AS2 would not forward traffic according to AS1's policy. - Additionally, AS2 can lose traffic share for the overlapping prefix - from customers different from AS1. + example described in Figure 11: if AS2 or AS3 filter prefix 10.0.0.0/ + 24, there would be no unexpected traffic flow in AS2. Nevertheless, + as described in Section 5.1, the filtering of overlapping prefixes + can generate conflicts between AS1 and AS2, since AS2 would not + forward traffic according to AS1's policy. Additionally, AS2 can + lose traffic share for the overlapping prefix from customers + different from AS1. 5.2.3. Neighbor-specific forwarding An operator can technically ensure that traffic destined to a given prefix will be forwarded from an entry point of the network based only on the set of paths that have been advertised over that entry point. As an example, let us analyze the scenario of Figure 11 from the point of view of AS2. The edge router connecting to the AS4 forward @@ -815,39 +819,40 @@ different options for dealing with this kind of problems, we recommend potential victims to implement monitoring systems that can detect them and react to them according to the specific situation. Although we observe that there are reasonable situations in which ASes could filter overlapping prefixes, we encourage that network operators implement this type of filters only after considering the cases described in this document. 7. References - [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM - Computer Communication Review vol. 38, no. 2, pp. 55-59, - April 2008. + [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM + SIGCOMM Computer Communication Review vol. 38, no. 2, pp. + 55-59, April 2008. - [2] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford, - "Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco - Systems, Routing - Symposium http://www.cs.princeton.edu/~jrex/talks/ - cisconag09.pdf, October 2009. + [2] Vanbever, L., Francois, P., Bonaventure, O., and J. + Rexford, "Customized BGP Route Selection Using BGP/MPLS + VPNs", Cisco Systems, Routing Symposium + http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf, + October 2009. - [3] "INIT7-RIPE63", . + [3] "INIT7-RIPE63", . - [4] +7.2. URIs - [5] + [1] http://www.ietf.org/rfc/rfc1812.txt - [6] + [2] http://tools.ietf.org/html/draft-white-grow-overlapping-routes-02 + + [3] http://www.ietf.org/rfc/rfc4384.txt Authors' Addresses Camilo Cardona IMDEA Networks/UC3M Avenida del Mar Mediterraneo, 22 Leganes 28919 Spain Email: juancamilo.cardona@imdea.org @@ -844,17 +849,25 @@ Authors' Addresses Camilo Cardona IMDEA Networks/UC3M Avenida del Mar Mediterraneo, 22 Leganes 28919 Spain Email: juancamilo.cardona@imdea.org + Pierre Francois IMDEA Networks Avenida del Mar Mediterraneo, 22 Leganes 28919 Spain Email: pierre.francois@imdea.org + Paolo Lucente + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA + + Email: plucente@cisco.com