Network Working Group Pierre Francois Internet-Draft Bruno Quoitin Intended status: Informational Universite catholique de Louvain Expires: January 7, 2010 July 6, 2009 Threat to BGP Policies : limited-scope more specific prefix injection draft-francois-limited-scope-specifics-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 7, 2010. Copyright Notice Copyright (c) 2009 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 Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 1] Internet-Draft Limited-scope more specifics : Threats July 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This draft describes potential threats to the respect of Internet routing policies by the routers of one ISP, that are due to a restricted propagation of more specific BGP prefixes by its neighboring domains. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Limiting the scope of prefix advertisement . . . . . . . . . . 3 3. Uses of limited scope more specifics that violate policies . . 4 3.1. Initial setup . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Injection of a more specific . . . . . . . . . . . . . . . 5 3.3. Limiting the scope of the more specific . . . . . . . . . . 6 3.4. Techniques to detect dataplane-based policy violations . . 8 3.5. Techniques to counter such violations . . . . . . . . . . . 8 3.5.1. Reactions . . . . . . . . . . . . . . . . . . . . . . . 8 3.5.2. Anticipant counter-measures . . . . . . . . . . . . . . 9 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 2] Internet-Draft Limited-scope more specifics : Threats July 2009 1. Introduction BGP policy configuration within an ISP network drives the control plane decisions on the nexthop to be used to reach a given prefix. However, in the data plane, the longest prefix match forwarding rule "precedes" the application of such policies. In other words, the existence of a prefix p' that is more specific than a prefix p in the Routing Information Base will let packets whose destination matches p' be forwarded according to the best nexthop obtained for p', disregarding the policies applied in the control plane for selection of the best nexthop for p. Through selected advertisements of a more specific prefix by some other ISPs, the configured policies of an ISP can be violated due to this essential data-plane/control-plane difference. This document presents such potential threats, and discusses solutions to the problem. It also describes the opportunities bound with that aspect of BGP routing. 2. Limiting the scope of prefix advertisement ISPs can tag the BGP paths that they propagate to neighboring ASes with communities, so as to tweak the propagation behavior of the ASes that handle such propagated paths. Some ISPs allow their direct and indirect customers to use such communities so as to let the receiving AS not export the path to some selected neighboring AS. Sometimes, such communities can be combined, so as to have the prefix advertised only to a given peer of the AS providing the "feature". Some operators also allow their direct and indirect customers to use communities so as to let the receiving AS not export that path to other ASes at all. Aggregation practices, such as "XXX reserves the right to aggregate any announcement for a network smaller than /length when advertising to external peers such as YYY", may implicetly lead to a limitation of the scope of the advertisement of a path towards a given prefix. Any such feature available to the customers of an AS, AS B, which allow the routing in AS B to result in the propagation of a given prefix to a neighboring AS, AS A, only, lets AS A face a potential violation of its policies in the data-plane. Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 3] Internet-Draft Limited-scope more specifics : Threats July 2009 More generally, any such features available to the customers of AS B, which allow the routing in AS B to result in the propagation of a given prefix to a neighboring AS, AS A, but not to some ASes outside the customer branch of A and B, lets AS A face a potential violation of its policies in the data-plane. 3. Uses of limited scope more specifics that violate policies In this section, we present a configuration scenario that leads to a data-plane violation of the policies of an AS, AS A. We incrementally build the scenario for the ease of understanding. Note that this example does not capture all the cases where such policy violation can take place. More examples will be provided in the future version of the document. 3.1. Initial setup Let AS_cust be a customer AS of AS A and AS B. It owns 10.0.0.0/22, which it advertises through AS A and AS B. Both AS A and AS B select that customer path as best, and propagate that path to their customers, providers, and peers. Some remote ASes will route traffic destined to 10.0.0.0 through (... A Cust 10.0.0.0/24) while some others will route traffic along (... B Cust 10.0.0.0/24). Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 4] Internet-Draft Limited-scope more specifics : Threats July 2009 \ / \ / /22 \ //22 /22 \ //22 ,-----. ,-----. ,' `. ,' `. / A \ /22 / B \ ( )-------------( ) \ / /22 \ / `. ,' `. ,' '-----; / '-----' \ / \ / 10.0.0.0/22\ /10.0.0.0/22 \ / \ ,-----.' ,' `. / Cust \ ( ) \ / `. ,' '-----' Figure 1: Example scenario 3.2. Injection of a more specific Let us assume that AS A and AS B are peers. Let AS_cust advertise 10.0.0.0/24 over AS B only. AS B propagate a path to 10.0.0.0/24 to its customers, provider and peers, including AS A. From AS A's point of view, such a path is a "peer path", so that this path will only be advertised to its customers. All the ASes that are not in the customer branch of AS A will receive a path to the /24 that contains AS B, and not AS A, as AS A has not relayed that path to other ASes than its customers. The ASes that are in the customer branch of AS A will receive a path to the /24 that contains AS B and AS A, as AS A has propagated that path to its customers. Some multi-homed customers of ISP A may also receive a path through ISP B, but not through ISP A, from other peering or provider links. Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 5] Internet-Draft Limited-scope more specifics : Threats July 2009 \ / /22\ //22 /22 \ //22 /24 \ / /24 ,-----. ,-----. ,' `. /22 ,' `. / A \ /24 / B \ ( /22:Cust )-------------( /22:Cust ) \ /24:B / /22 \ /24:Cust / /22 /`. ,' `. ,' /24/ '-----; / '-----' / \ / ,---./ \ / / \ 10.0.0.0/22\ /10.0.0.0/22 (Cust_2 ) \ / 10.0.0.0/24 \ / \ ,-----.' `---' ,' `. / Cust \ ( ) \ / `. ,' '-----' Figure 2: More Specific Injection Any remote AS that is not lying in the customer branch of A, will receive a path for 10.0.0.0/24 through AS B and not through AS A. Routing is consistent with usual Internet Routing Policies here, as AS A may only receive traffic destined to 10.0.0.0/24 from its customers, which it forwards to its peer AS B. AS B may receive traffic destined to 10.0.0.0/24 from its customers, providers, and peers, which it directly forwards to its customer AS Cust. 3.3. Limiting the scope of the more specific Now, let us assume that 10.0.0.0/24, which is propagated by AS_Cust to AS B, is tagged so as to have AS B only propagate that path to AS A, using the techniques described in Section 2. Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 6] Internet-Draft Limited-scope more specifics : Threats July 2009 ,-------. ,' `. / AS_Src \ ( /22:A ) \ / `. ,' '-------' \ / \ / /22 \ //22 /22 \ //22 ,-----. ,-----. ,' `. /22 ,' `. / A \ /24 / B \ ( /22:Cust )-------------( /22:Cust ) \ /24:B / /22 \ /24:Cust / /22 /`. ,' `. ,' /24/ '-----; / '-----' / \ / ,---./ \ / / \ 10.0.0.0/22\ /10.0.0.0/22 (Cust_2 ) \ / 10.0.0.0/24 \ / \ ,-----.' `---' ,' `. / Cust \ ( ) \ / `. ,' '-----' Figure 3: More Specific Injection From AS A's point of view, such a path is a "peer path", so that this path will only be advertised to the customers of AS A by AS A. All the ASes that are not in the customer branch of AS A nor in the customer branch of AS B will NOT receive a path to 10.0.0.0/24. All these ASes will forward packets destined to 10.0.0.0/24 according to their routing state for 10.0.0.0/22. Let us assume that AS_Src is such an AS, and that its best path towards 10.0.0.0/22 is through AS A. In that case, packets sent towards 10.0.0.1 by AS_Src will eventually reach AS A. However, in the dataplane of the nodes of AS A, the longest prefix match for 10.0.0.0 is 10.0.0.0/24, that is reached through AS B, a peer of AS A. As AS_Src is by definition not in the customer branch of AS A, we are in a situation such that AS A is forwarding non customer originated Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 7] Internet-Draft Limited-scope more specifics : Threats July 2009 traffic along peering links, which is a violation of its policies. If the path towards 10.0.0.0/24 is propagated by B to its customers, the traffic originated by ASes in the customer branch of AS A will not follow policy-violating data-plane paths as the forwarding of traffic towards these destinations will always be based on FIB entries for 10.0.0.0/24. However, policy-violation can still take place for the traffic originated from all ASes that are neither in the customer branch of A nor in the customer branch of B, and which select a path through AS A to reach 10.0.0.0/22 3.4. Techniques to detect dataplane-based policy violations Detecting such a violation can be done by monitoring NetFlow data in the ISP so as to see if flows entering the ISP network through a non- customer link is being forwarded to a non-customer nexthop. Detecting such a violation can be done by looking at BGP data to see whether there exists in the RIB a prefix P/p more specific than P/p' such that the nexthop for P/p is through a peer (or a provider) while P/p' is routed through a customer. For each such couple of prefixes, looking glasses around the providers and peers of the current AS should be consulted to see if these ASes are propagating a path towards P/p' (and not towards P/p) to their own customer, peers, or providers. This should trigger a warning as this would mean that ASes in the surrounding area of the current AS are forwarding packets based on the routing entry for the less specific prefix only. 3.5. Techniques to counter such violations Operators can adopt different positions regarding such kind of policy violations. We classify such positions according to whether they are anticipant or reactive. Reactive positions are those such that the operator tries to detect such situations and solves the policy violation through other means than using the routing system. Anticipant positions are those such that the routing system will not let the policy violation actually take place when the configuration scenario is set up. 3.5.1. Reactions An operator who detects that its policies have been violated can contact the operators that are likely to have performed the propagation tweaks so as to change the behavior. Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 8] Internet-Draft Limited-scope more specifics : Threats July 2009 An operator can account the amount of traffic that has been subject to policy violation, and charge the peer that received the policy- violating traffic. That is, the operator can claim that it has been a provider of that peer for that part of the traffic that transited between the two ASes. An operator can decide to filter-out the concerned more specific prefix at the peering session over which it was received. In the example of Figure 3, AS A would filter out 10.0.0.0/24 in its eBGP in-filter associated with the eBGP session with AS B. As a result, the traffic destined to that /24 would be forwarded by AS A along its link with AS_Cust, despite the actions performed by AS_Cust to have this traffic coming in through it link with AS B. 3.5.2. Anticipant counter-measures 3.5.2.1. Neighbor-specific forwarding An operator can technically ensure that the traffic destined to a given prefix will be forwarded from an entry point of the AS, only on the basis of the set of paths that have been advertised over that entry point. 3.5.2.2. Neighbor-specific filtering An operator can configure its routers so as to have them dynamically install an access-list made of the prefixes towards which the forwarding of traffic from that interface would lead to a policy violation. Note that this technique actually lets packets destined to a valid prefix be dropped while they are sent from a neighboring AS that cannot know about the policy violation and hence had no means to avoid the policy violation. In the example of Figure 3, AS A would install an access-list denying packets matching 10.0.0.0/24 associated with the interface connecting AS_Src. As a result, the traffic destined to that /24 would be dropped, despite the existence of a non policy-violating route towards 10.0.0.0/22. 4. References Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 9] Internet-Draft Limited-scope more specifics : Threats July 2009 Authors' Addresses Pierre Francois Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE Email: pierre.francois@uclouvain.be URI: http://inl.info.ucl.ac.be/pfr Bruno Quoitin Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE Email: bruno.quoitin@uclouvain.be URI: http://inl.info.ucl.ac.be/bqu Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 10]