draft-ietf-grow-filtering-threats-07.txt   draft-ietf-grow-filtering-threats-08.txt 
Network Working Group Camilo Cardona Network Working Group Camilo Cardona
Internet-Draft IMDEA Networks/UC3M Internet-Draft IMDEA Networks/UC3M
Intended status: Informational Pierre Francois Intended status: Informational Pierre Francois
Expires: January 28, 2016 IMDEA Networks Expires: May 11, 2016 Paolo Lucente
Paolo Lucente
Cisco Systems Cisco Systems
July 27, 2015 November 08, 2015
Impact of BGP filtering on Inter-Domain Routing Policies Impact of BGP filtering on Inter-Domain Routing Policies
draft-ietf-grow-filtering-threats-07 draft-ietf-grow-filtering-threats-08
Abstract Abstract
This document describes how unexpected traffic flows can emerge This document describes how unexpected traffic flows can emerge
across an autonomous system, as the result of other autonomous across an autonomous system, as the result of other autonomous
systems filtering, or restricting the propagation of more specific systems filtering, or restricting the propagation of more specific
prefixes. We provide a review of the techniques to detect the prefixes. We provide a review of the techniques to detect the
occurrence of this issue and defend against it. occurrence of this issue and defend against it.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 8 skipping to change at page 8, line 8
forward packets destined to 2001:DB8::/34 according to their routing forward packets destined to 2001:DB8::/34 according to their routing
state for 2001:DB8::/32. Let us assume that AS64505 is such an AS, 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. and that its best path towards 2001:DB8::/32 is through AS64502.
Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502. Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502.
However, in the data-plane of the nodes of AS64502, the longest 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 prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached
through AS64503, a settlement-free peer of AS64502. Since AS64505 is through AS64503, a settlement-free peer of AS64502. Since AS64505 is
not in the customer branch of AS64502, traffic flows between two non- not in the customer branch of AS64502, traffic flows between two non-
customer ASes in AS64502. customer ASes in AS64502.
,-----. ,-----.
,' `. ------- Connections to other ASes ,' `.
/ AS64505 \ /32 / AS64505 \
( ) <-+ ( )
\ / \ /
`. ,' ,`. ,' \
'-----' / '-----' \
^ \ / ^ ^ \ / ^ / ^ ^ \
| /32 \ / /32 | | /32 \ / /32 | /32 | | /32 '
+ ,-----. + + ,-----. + ,-----.' + + ,-----.
,' `. ,' `. ,' `. ,' `.
/ AS64502 \ / AS64503 \ / AS64502 \ / AS64503 \
( )-------------( ) ( )-------------( )
,-----. \ / /32 /32 \ / \ / /32 /32 \ /
,' `.---------`. ,' +-> /34 `. ,' `. ,' +-> /34 `. ,'
/ AS64504 \ /32 '-----; <-+ / '-----' '-----; <-+ / '-----'
( ) /34 \ / \ /
\ / <-+ ^ \ / ^ ^ \ / ^
`. ,' | \ / | | \ / |
'-----; | \ / | | \ / |
| \ ,-----.' | 2001:DB8::/32 | \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34 | ,' `. | 2001:DB8::/34
2001:DB8::/32 +--+ / AS64501 \ +--+ 2001:DB8::/32 +--+ / AS64501 \ +--+
( ) ( )
\ / \ /
`. ,' `. ,'
'-----' '-----'
Figure 4: Unexpected traffic flows due to remote triggered filtering Figure 4: Unexpected traffic flows due to remote triggered filtering
3. Techniques to detect unexpected traffic flows caused by filtering of 3. Techniques to detect unexpected traffic flows caused by filtering of
more specific prefixes more specific prefixes
3.1. Existence of unexpected traffic flows within an AS 3.1. Existence of unexpected traffic flows within an AS
To detect if unexpected traffic flows are taking place in its To detect if unexpected traffic flows are taking place in its
network, an ISP can monitor its traffic data to check if it is network, an ISP can monitor its traffic data to check if it is
skipping to change at page 9, line 20 skipping to change at page 9, line 20
verify the correctness of the BGP configuration. verify the correctness of the BGP configuration.
Once the local configuration is confirmed correct, the operator Once the local configuration is confirmed correct, the operator
should check if the unexpected flow arose due to filtering of BGP should check if the unexpected flow arose due to filtering of BGP
paths for more-specific prefixes by neighboring ASes. This can be paths for more-specific prefixes by neighboring ASes. This can be
performed in two steps. First, the operator should check whether the performed in two steps. First, the operator should check whether the
neighboring AS originating the unexpected flow is forwarding traffic neighboring AS originating the unexpected flow is forwarding traffic
using a less-specific prefix that is announced to it by the affected 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 network. The second step is to try to infer the reason why the
neighboring AS does not use the more specific path for forwarding, neighboring AS does not use the more specific path for forwarding,
i.e., finding why the more specific prefix was filtered. The authors i.e., finding why the more specific prefix was filtered. Due to the
note that due to the distributed nature and restricted visibility of distributed nature and restricted visibility of the steering of BGP
the steering of BGP policies, this second step is deemed to not policies, this second step does not identify the origin of the
identify the origin of the problem with guaranteed accuracy. problem with guaranteed accuracy.
For the first step, the operator should check if the destination For the first step, the operator should check if the destination
address of the unexpected traffic flow is locally routed as per a address of the unexpected traffic flow is locally routed as per a
more specific prefix only received from non-customer peers. The more specific prefix only received from non-customer peers. The
operator should also check if there are paths to a less specific operator should also check if there are paths to a less specific
prefix received from a customer, and hence propagated to peers. If prefix received from a customer, and hence propagated to peers. If
these two situations happen at the same time, the neighboring AS at these two situations happen at the same time, the neighboring AS at
the entry point of the unexpected flow is routing the traffic based the entry point of the unexpected flow is routing the traffic based
on the less specific prefix, although the ISP is actually forwarding on the less specific prefix, although the ISP is actually forwarding
the traffic via non-customer links. the traffic via non-customer links.
For the second step, one can rely on human interaction or looking For the second step, one can rely on human interaction or looking
glasses to find out whether local filtering, remote filtering, or glasses to find out whether local filtering, remote filtering, or
selective propagation was performed on the more specific prefix. The selective propagation was performed on the more specific prefix. No
authors are not aware, at the time of this writing, of any openly openly available tools that can automatically perform this operation
available tool that can automatically perform this operation. have been identified.
3.2. Contribution to the existence of unexpected traffic flows in 3.2. Contribution to the existence of unexpected traffic flows in
another AS another AS
It can be considered problematic to trigger unexpected traffic flows 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 in another AS. It is thus advisable for an AS to assess the risks of
filtering more specific prefixes before implementing them, by filtering more specific prefixes before implementing them, by
obtaining as much information as possible about its surrounding obtaining as much information as possible about its surrounding
routing environment. routing environment.
skipping to change at page 10, line 19 skipping to change at page 10, line 19
In order to assess the risk of filtering more specific prefixes, the In order to assess the risk of filtering more specific prefixes, the
AS would need information on the routing policies and the AS would need information on the routing policies and the
relationships among external ASes, to detect if its actions could relationships among external ASes, to detect if its actions could
trigger the appearance of unexpected traffic flows. With this trigger the appearance of unexpected traffic flows. With this
information, the operator could detect other ASes receiving the more information, the operator could detect other ASes receiving the more
specific prefix from non-customer ASes, while announcing the less specific prefix from non-customer ASes, while announcing the less
specific prefix to other non-customer ASes. If the filtering of the specific prefix to other non-customer ASes. If the filtering of the
more specific prefix leads other ASes to send traffic for the more more specific prefix leads other ASes to send traffic for the more
specific prefix to these ASes, an unexpected traffic flow can arise. specific prefix to these ASes, an unexpected traffic flow can arise.
However, the information required for this operation is difficult to However, the information required for this operation is difficult to
obtain, due to the distributed nature of BGP policies. We are not obtain since it is frequently considered confidential.
aware, at the time of this writing, of any openly available tool that
can automatically perform this procedure.
4. Techniques to Traffic Engineer unexpected flows 4. Techniques to Traffic Engineer unexpected flows
Network Operators can adopt different approaches with respect to Network Operators can adopt different approaches with respect to
unexpected traffic flows. Note that due the complexity of inter- unexpected traffic flows. Note that due the complexity of inter-
domain routing policies, there is not a single solution that can be domain routing policies, there is not a single solution that can be
applied to all situations. This section provides potential solutions applied to all situations. This section provides potential solutions
that ISPs must evaluate against each particular case. We classify that ISPs must evaluate against each particular case. We classify
these actions according to whether they are proactive or reactive. these actions according to whether they are proactive or reactive.
Reactive approaches are those in which the operator tries to detect Reactive approaches are those in which the operator tries to detect
the situations via monitoring and solve unexpected traffic flows, the situations via monitoring and solve unexpected traffic flows,
manually, on a case-by-case basis. manually, on a case-by-case basis.
Anticipant or preventive approaches are those in which the routing Anticipant or preventive approaches are those in which the routing
system will not let the unexpected traffic flows actually take place system will not let the unexpected traffic flows actually take place
when the scenario arises. when the scenario arises.
We use the scenario depicted in Figure 5 to describe these two kinds We use the scenario depicted in Figure 5 to describe these two kinds
of approaches. The authors observe that proactive approaches can be of approaches. Since proactive approaches can be complex to
complex to implement and can lead to undesired effects, and thus implement and can lead to undesired effects, the reactive approach is
conclude that the reactive approach is the more reasonable the more reasonable recommendation to deal with unexpected flows.
recommendation to deal with unexpected flows.
____,,................______ ____,,................______
_,.---'''' `''---..._ _,.---'''' `''---..._
,-'' AS64505 `-. ,-'' AS64505 `-.
[ / [ /
-.._ __.-' -.._ __.-'
. `'---....______ ______...---'' . `'---....______ ______...---''
+ |/32 `''''''''''''''' | + |/32 `''''''''''''''' |
| |/34 + |/32 | | |/34 + |/32 |
v | v |/34 | v | v |/34 |
skipping to change at page 14, line 6 skipping to change at page 14, line 6
of AS64501. of AS64501.
5. Conclusions 5. Conclusions
This document describes how filtering and selective propagation of This document describes how filtering and selective propagation of
more-specific prefixes can potentially create unexpected traffic more-specific prefixes can potentially create unexpected traffic
flows across some ASes. We provided examples of scenarios where flows across some ASes. We provided examples of scenarios where
these practices lead to unexpected traffic flows, and introduce some these practices lead to unexpected traffic flows, and introduce some
techniques for their detection and prevention. Although there are techniques for their detection and prevention. Although there are
reasonable situations in which ASes could filter more-specific reasonable situations in which ASes could filter more-specific
prefixes, authors encourage network operators to implement this type prefixes, network operators are encouraged to implement this type of
of filters considering the cases described in this document. filters considering the cases described in this document. Operators
Analyzing the different options for dealing with such situations, can implement monitoring systems to detect unexpected traffic flows
authors recommend ASes to implement monitoring systems that can and react to them according to their own policy.
detect violations and react to them on a case-by-case basis,
according to their own policy.
6. Security Considerations 6. Security Considerations
It is possible for an AS to use any of the methods described in this It is possible for an AS to use any of the methods described in this
document to deliberately reroute traffic flowing through another AS. document to deliberately reroute traffic flowing through another AS.
The objective of this document is to inform on this potential routing This document informed on the potential routing security issue, and
security issue, and analyze ways for operators to defend against analyzed ways for operators to defend against it.
them.
It must be noted that, at the time of this document, there are no It must be noted that, at the time of this document, there are no
existing or proposed tools to automatically protect against such existing or proposed tools to automatically protect against such
behavior. Operators can use network monitoring and collection tools behavior. Operators can use network monitoring and collection tools
to detect unexpected flows and deal with them on a case-by-case to detect unexpected flows and deal with them on a case-by-case
basis. basis.
7. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
skipping to change at page 15, line 37 skipping to change at page 15, line 37
Camilo Cardona Camilo Cardona
IMDEA Networks/UC3M IMDEA Networks/UC3M
Avenida del Mar Mediterraneo, 22 Avenida del Mar Mediterraneo, 22
Leganes 28919 Leganes 28919
Spain Spain
Email: juancamilo.cardona@imdea.org Email: juancamilo.cardona@imdea.org
Pierre Francois Pierre Francois
IMDEA Networks Cisco Systems
Avenida del Mar Mediterraneo, 22 170 W. Tasman Drive
Leganes 28919 San Jose, CA 95134
Spain USA
Email: pierre.francois@imdea.org Email: pifranco@cisco.com
Paolo Lucente Paolo Lucente
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: plucente@cisco.com Email: plucente@cisco.com
 End of changes. 13 change blocks. 
60 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/