--- 1/draft-ietf-grow-filtering-threats-07.txt 2015-11-07 17:15:18.118112196 -0800 +++ 2/draft-ietf-grow-filtering-threats-08.txt 2015-11-07 17:15:18.210114444 -0800 @@ -1,21 +1,20 @@ Network Working Group Camilo Cardona Internet-Draft IMDEA Networks/UC3M Intended status: Informational Pierre Francois -Expires: January 28, 2016 IMDEA Networks - Paolo Lucente +Expires: May 11, 2016 Paolo Lucente Cisco Systems - July 27, 2015 + November 08, 2015 Impact of BGP filtering on Inter-Domain Routing Policies - draft-ietf-grow-filtering-threats-07 + draft-ietf-grow-filtering-threats-08 Abstract This document describes how unexpected traffic flows can emerge across an autonomous system, as the result of other autonomous systems filtering, or restricting the propagation of more specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it. Status of This Memo @@ -26,21 +25,21 @@ 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 January 28, 2016. + This Internet-Draft will expire on May 11, 2016. Copyright Notice Copyright (c) 2015 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 @@ -319,39 +318,39 @@ state for 2001:DB8::/32. Let us assume that AS64505 is such an AS, and that its best path towards 2001:DB8::/32 is through AS64502. Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502. However, in the data-plane of the nodes of AS64502, the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached through AS64503, a settlement-free peer of AS64502. Since AS64505 is not in the customer branch of AS64502, traffic flows between two non- customer ASes in AS64502. ,-----. - ,' `. ------- Connections to other ASes - / AS64505 \ /32 - ( ) <-+ + ,' `. + / AS64505 \ + ( ) \ / - `. ,' - '-----' - ^ \ / ^ ^ \ / ^ - | /32 \ / /32 | | /32 \ / /32 | - + ,-----. + + ,-----. + + ,`. ,' \ + / '-----' \ + / ^ ^ \ + /32 | | /32 ' + ,-----.' + + ,-----. ,' `. ,' `. / AS64502 \ / AS64503 \ ( )-------------( ) - ,-----. \ / /32 /32 \ / - ,' `.---------`. ,' +-> /34 `. ,' - / AS64504 \ /32 '-----; <-+ / '-----' - ( ) /34 \ / - \ / <-+ ^ \ / ^ - `. ,' | \ / | - '-----; | \ / | + \ / /32 /32 \ / + `. ,' +-> /34 `. ,' + '-----; <-+ / '-----' + \ / + ^ \ / ^ + | \ / | + | \ / | | \ ,-----.' | 2001:DB8::/32 | ,' `. | 2001:DB8::/34 2001:DB8::/32 +--+ / AS64501 \ +--+ ( ) \ / `. ,' '-----' Figure 4: Unexpected traffic flows due to remote triggered filtering @@ -378,40 +377,40 @@ verify the correctness of the BGP configuration. Once the local configuration is confirmed correct, the operator should check if the unexpected flow arose due to filtering of BGP paths for more-specific prefixes by neighboring ASes. This can be performed in two steps. First, the operator should check whether the neighboring AS originating the unexpected flow is forwarding traffic using a less-specific prefix that is announced to it by the affected network. The second step is to try to infer the reason why the neighboring AS does not use the more specific path for forwarding, - i.e., finding why the more specific prefix was filtered. The authors - note that due to the distributed nature and restricted visibility of - the steering of BGP policies, this second step is deemed to not - identify the origin of the problem with guaranteed accuracy. + i.e., finding why the more specific prefix was filtered. Due to the + distributed nature and restricted visibility of the steering of BGP + policies, this second step does not identify the origin of the + problem with guaranteed accuracy. For the first step, the operator should check if the destination address of the unexpected traffic flow is locally routed as per a more specific prefix only received from non-customer peers. The operator should also check if there are paths to a less specific prefix received from a customer, and hence propagated to peers. If these two situations happen at the same time, the neighboring AS at the entry point of the unexpected flow is routing the traffic based on the less specific prefix, although the ISP is actually forwarding the traffic via non-customer links. For the second step, one can rely on human interaction or looking glasses to find out whether local filtering, remote filtering, or - selective propagation was performed on the more specific prefix. The - authors are not aware, at the time of this writing, of any openly - available tool that can automatically perform this operation. + selective propagation was performed on the more specific prefix. No + openly available tools that can automatically perform this operation + have been identified. 3.2. Contribution to the existence of unexpected traffic flows in another AS It can be considered problematic to trigger unexpected traffic flows in another AS. It is thus advisable for an AS to assess the risks of filtering more specific prefixes before implementing them, by obtaining as much information as possible about its surrounding routing environment. @@ -425,46 +424,43 @@ In order to assess the risk of filtering more specific prefixes, the AS would need information on the routing policies and the relationships among external ASes, to detect if its actions could trigger the appearance of unexpected traffic flows. With this information, the operator could detect other ASes receiving the more specific prefix from non-customer ASes, while announcing the less specific prefix to other non-customer ASes. If the filtering of the more specific prefix leads other ASes to send traffic for the more specific prefix to these ASes, an unexpected traffic flow can arise. However, the information required for this operation is difficult to - obtain, due to the distributed nature of BGP policies. We are not - aware, at the time of this writing, of any openly available tool that - can automatically perform this procedure. + obtain since it is frequently considered confidential. 4. Techniques to Traffic Engineer unexpected flows Network Operators can adopt different approaches with respect to unexpected traffic flows. Note that due the complexity of inter- domain routing policies, there is not a single solution that can be applied to all situations. This section provides potential solutions that ISPs must evaluate against each particular case. We classify these actions according to whether they are proactive or reactive. Reactive approaches are those in which the operator tries to detect the situations via monitoring and solve unexpected traffic flows, manually, on a case-by-case basis. Anticipant or preventive approaches are those in which the routing system will not let the unexpected traffic flows actually take place when the scenario arises. We use the scenario depicted in Figure 5 to describe these two kinds - of approaches. The authors observe that proactive approaches can be - complex to implement and can lead to undesired effects, and thus - conclude that the reactive approach is the more reasonable - recommendation to deal with unexpected flows. + of approaches. Since proactive approaches can be complex to + implement and can lead to undesired effects, the reactive approach is + the more reasonable recommendation to deal with unexpected flows. ____,,................______ _,.---'''' `''---..._ ,-'' AS64505 `-. [ / -.._ __.-' . `'---....______ ______...---'' + |/32 `''''''''''''''' | | |/34 + |/32 | v | v |/34 | @@ -598,34 +594,31 @@ of AS64501. 5. Conclusions This document describes how filtering and selective propagation of more-specific prefixes can potentially create unexpected traffic flows across some ASes. We provided examples of scenarios where these practices lead to unexpected traffic flows, and introduce some techniques for their detection and prevention. Although there are reasonable situations in which ASes could filter more-specific - prefixes, authors encourage network operators to implement this type - of filters considering the cases described in this document. - Analyzing the different options for dealing with such situations, - authors recommend ASes to implement monitoring systems that can - detect violations and react to them on a case-by-case basis, - according to their own policy. + prefixes, network operators are encouraged to implement this type of + filters considering the cases described in this document. Operators + can implement monitoring systems to detect unexpected traffic flows + and react to them according to their own policy. 6. Security Considerations It is possible for an AS to use any of the methods described in this document to deliberately reroute traffic flowing through another AS. - The objective of this document is to inform on this potential routing - security issue, and analyze ways for operators to defend against - them. + This document informed on the potential routing security issue, and + analyzed ways for operators to defend against it. It must be noted that, at the time of this document, there are no existing or proposed tools to automatically protect against such behavior. Operators can use network monitoring and collection tools to detect unexpected flows and deal with them on a case-by-case basis. 7. IANA Considerations This document has no IANA actions. @@ -677,24 +670,24 @@ 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 + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA - Email: pierre.francois@imdea.org + Email: pifranco@cisco.com Paolo Lucente Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: plucente@cisco.com