draft-ietf-grow-filtering-threats-05.txt   draft-ietf-grow-filtering-threats-06.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: August 27, 2015 IMDEA Networks Expires: December 11, 2015 IMDEA Networks
Paolo Lucente Paolo Lucente
Cisco Systems Cisco Systems
February 23, 2015 June 9, 2015
Impact of BGP filtering on Inter-Domain Routing Policies Impact of BGP filtering on Inter-Domain Routing Policies
draft-ietf-grow-filtering-threats-05 draft-ietf-grow-filtering-threats-06
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 37
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 August 27, 2015. This Internet-Draft will expire on December 11, 2015.
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 2, line 24 skipping to change at page 2, line 24
2.1.1. Unexpected traffic flows caused by local filtering of 2.1.1. Unexpected traffic flows caused by local filtering of
more specific prefixes . . . . . . . . . . . . . . . 5 more specific prefixes . . . . . . . . . . . . . . . 5
2.2. Remote filtering . . . . . . . . . . . . . . . . . . . . 6 2.2. Remote filtering . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Unexpected traffic flows caused by remotely triggered 2.2.1. Unexpected traffic flows caused by remotely triggered
filtering of more specific prefixes . . . . . . . . . 7 filtering of more specific prefixes . . . . . . . . . 7
3. Techniques to detect unexpected traffic flows caused by 3. Techniques to detect unexpected traffic flows caused by
filtering of more specific prefixes . . . . . . . . . . . . . 8 filtering of more specific prefixes . . . . . . . . . . . . . 8
3.1. Existence of unexpected traffic flows within an AS . . . 8 3.1. Existence of unexpected traffic flows within an AS . . . 8
3.2. Contribution to the existence of unexpected traffic flows 3.2. Contribution to the existence of unexpected traffic flows
in another AS . . . . . . . . . . . . . . . . . . . . . . 9 in another AS . . . . . . . . . . . . . . . . . . . . . . 9
4. Techniques to counter unexpected traffic flows . . . . . . . 10 4. Techniques to Traffic Engineer unexpected traffic flows . . . 10
4.1. Reactive counter-measures . . . . . . . . . . . . . . . . 11 4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11
4.2. Proactive counter-measures . . . . . . . . . . . . . . . 12 4.2. Proactive measures . . . . . . . . . . . . . . . . . . . 12
4.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Neighbor-specific forwarding . . . . . . . . . . . . 13 4.2.2. Neighbor-specific forwarding . . . . . . . . . . . . 13
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Informative References . . . . . . . . . . . . . . . . . 14 9.1. Informative References . . . . . . . . . . . . . . . . . 14
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 34 skipping to change at page 4, line 34
specific prefix. Such a practice was notably documented in [3] (2) specific prefix. Such a practice was notably documented in [3] (2)
Enforcing contract compliance, where, for instance, an AS avoids a Enforcing contract compliance, where, for instance, an AS avoids a
settlement-free peer to attract traffic to one link by using settlement-free peer to attract traffic to one link by using
selective advertisement, when this is not allowed by their peering selective advertisement, when this is not allowed by their peering
agreement. (3) The need for Forwarding Information Base memory agreement. (3) The need for Forwarding Information Base memory
preservation sometimes pushes ISP operators to filter more specific preservation sometimes pushes ISP operators to filter more specific
prefixes. prefixes.
Figure 1 illustrates a scenario in which one AS is motivated to Figure 1 illustrates a scenario in which one AS is motivated to
perform local filtering due to outbound traffic engineering. The perform local filtering due to outbound traffic engineering. The
figure depicts AS64504, and two of its neighboring ASes, AS64502 and figure depicts AS64504, and two of its neighboring ASes, AS64502, and
AS64505. AS64504 has a settlement-free peering with AS64502 and is a AS64505. AS64504 has a settlement-free peering with AS64502 and is a
customer of AS64505. AS64504 receives from AS64505 prefixes customer of AS64505. AS64504 receives from AS64505 prefixes
2001:DB8::/32 and 2001:DB8::/34, a less specific and a more specific 2001:DB8::/32 and 2001:DB8::/34, a less specific and a more specific
prefix, respectively. AS64504 receives only the less specific prefix prefix, respectively. AS64504 receives only the less specific prefix
2001:DB8::/32 from AS64502. 2001:DB8::/32 from AS64502.
,-----. ,-----.
/ \ / \
( AS64505 ) ( AS64505 )
\ / \ /
skipping to change at page 9, line 13 skipping to change at page 9, line 13
be analyzed under the perspective of the business relationships with be analyzed under the perspective of the business relationships with
neighboring ASes. Open source tools such as [4] can be used to this neighboring ASes. Open source tools such as [4] can be used to this
end. end.
Note that the AS detecting the unexpected traffic flow may simply Note that the AS detecting the unexpected traffic flow may simply
realize that his policy configuration is broken. The first realize that his policy configuration is broken. The first
recommended action upon detection of an unexpected traffic flow is to recommended action upon detection of an unexpected traffic flow is to
verify the correctness of the BGP configuration. verify the correctness of the BGP configuration.
Once it has been assessed that the local configuration is correct, Once it has been assessed that the local configuration is correct,
the operator should check if the problem detected in the data-plane the operator should check if the unexpected flow arose due to
arose due to filtering of BGP paths by neighboring ASes. The filtering of BGP paths for more-specific prefixes by neighboring
operator should check if the destination address of the unexpected ASes. This can be performed in two steps. First, the operator
traffic flow is locally routed as per a more specific prefix only should check whether the neighboring AS originating the unexpected
received from non-customer peers. The operator should also checks if flow is forwarding traffic using a less-specific prefix that is
there are paths to a less specific prefix received from a customer, announced to it by the affected network. The second step is to try
and hence propagated to peers. If these two situations happen at the to infer the reason why the neighboring AS does not use the more-
same time, the neighboring AS at the entry point of the unexpected specific path for forwarding, i.e., finding why the more-specific
flow is routing the traffic based on the less specific prefix, prefix was filtered. We note that due to the distributed nature and
although the ISP is actually forwarding the traffic via non-customer restricted visibility of the steering of BGP policies, this second
links. step is deemed to not identify the origin of the problem with
guaranteed accuracy.
To detect the origin of the problem, human interaction or looking For the first step, the operator should check if the destination
glasses can be used in order to find out whether local filtering, address of the unexpected traffic flow is locally routed as per a
remote filtering, or selective propagation was performed on the more more specific prefix only received from non-customer peers. The
specific prefix. Due to the distributed nature and restricted operator should also check if there are paths to a less specific
visibility of the steering of BGP policies, such analysis is deemed prefix received from a customer, and hence propagated to peers. If
to not identify the origin of the problem with guaranteed accuracy. these two situations happen at the same time, the neighboring AS at
We are not aware, at the time of this writing, of any openly the entry point of the unexpected flow is routing the traffic based
available tool that can automatically perform this operation. on the less specific prefix, although the ISP is actually forwarding
the traffic via non-customer links.
For the second step, human interaction or looking glasses can be used
in order to find out whether local filtering, remote filtering, or
selective propagation was performed on the more specific prefix. We
are not aware, at the time of this writing, of any openly available
tool that can automatically perform this operation.
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 be causing unexpected traffic It can be considered problematic to be causing unexpected traffic
flows in other ASes. It is thus advisable for an AS to assess the flows in other ASes. It is thus advisable for an AS to assess the
risks of filtering more specific prefixes before implementing them by risks of filtering more specific prefixes before implementing them by
obtaining as much data information as possible about its surrounding obtaining as much data information as possible about its surrounding
routing environment. routing environment.
There may be justifiable reasons for one ISP to perform filtering; There may be justifiable reasons for one ISP to perform filtering;
either to enforce established policies or to provide prefix either to enforce established policies or to provide prefix
advertisement scoping features to its customers. These can vary from advertisement scoping features to its customers. These can vary from
trouble-shooting purposes to business relationship implementations. trouble-shooting purposes to business relationship implementations.
Restricting the use of these features for the sake of avoiding the Restricting the use of these features for the sake of avoiding the
creation of unexpected traffic flows is not a practical option. creation of unexpected traffic flows is not a practical option.
In order to assess the rist of filtering more specific prefixes, the In order to assess the risk of filtering more specific prefixes, the
AS would need information of 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, due to the distributed nature of BGP policies. We are not
aware, at the time of this writing, of any openly available tool that aware, at the time of this writing, of any openly available tool that
can automatically perform this procedure. can automatically perform this procedure.
4. Techniques to counter unexpected traffic flows 4. Techniques to Traffic Engineer unexpected traffic 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. We provide potential solutions that ISPs applied to all situations. We provide potential solutions that ISPs
must evaluate against each particular case. We classify these must evaluate against each particular case. We classify these
actions according to whether they are proactive or reactive. 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,
skipping to change at page 11, line 35 skipping to change at page 11, line 35
| ^ | | ^ |
^ |2001:DB8::/32 | |2001:DB8::/32 ^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34 | | + |2001:DB8::/34
+ | _....---------...._| + | _....---------...._|
,-'AS64501 ``-. ,-'AS64501 ``-.
/' `. /' `.
`. _, `. _,
`-.._ _,,,' `-.._ _,,,'
`''---------''' `''---------'''
Figure 5: Counter-measures for unexpected traffic flows - Base Figure 5: Traffic Engineering of unexpected traffic flows - Base
example example
4.1. Reactive counter-measures 4.1. Reactive Traffic Engineering
An operator who detects unexpected traffic flows originated by any of An operator who detects unexpected traffic flows originated by any of
the cases described in Section 2 can contact the ASes that are likely the cases described in Section 2 can contact the ASes that are likely
to have performed the propagation tweaks, inform them of the to have performed the propagation tweaks, inform them of the
situation, and persuade them to change their behavior. situation, and persuade them to change their behavior.
If the situation remains, the operator can implement prefix filtering If the situation remains, the operator can implement prefix filtering
in order to stop the unexpected flows. The operator can decide to in order to stop the unexpected flows. The operator can decide to
perform this action over the session with the operator announcing the perform this action over the session with the operator announcing the
more specific prefix or over the session with the neighboring AS from more specific prefix or over the session with the neighboring AS from
skipping to change at page 12, line 37 skipping to change at page 12, line 37
AS64501 in its BGP announcements. AS64501 in its BGP announcements.
It is possible that the behavior of the neighboring AS causing the It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows opposes the peering agreement. In this unexpected traffic flows opposes the peering agreement. In this
case, an operator could account the amount of traffic that has been case, an operator could account the amount of traffic that has been
subject to the unexpected flows, using traffic measurement protocols subject to the unexpected flows, using traffic measurement protocols
such as IPFIX, and charge the peer for that traffic. That is, the such as IPFIX, and charge the peer for that traffic. That is, the
operator can claim that it has been a provider of that peer for the operator can claim that it has been a provider of that peer for the
traffic that transited between the two ASes. traffic that transited between the two ASes.
4.2. Proactive counter-measures 4.2. Proactive measures
4.2.1. Access lists 4.2.1. Access lists
An operator could install access-lists to prevent unexpected traffic An operator could install access-lists to prevent unexpected traffic
flows from happening in the first place. In the example of Figure 5, flows from happening in the first place. In the example of Figure 5,
AS64502 would install an access-list denying packets matching AS64502 would install an access-list denying packets matching
2001:DB8::/34 associated with the interface connecting to AS64504. 2001:DB8::/34 associated with the interface connecting to AS64504.
As a result, traffic destined to that prefix would be dropped, As a result, traffic destined to that prefix would be dropped,
despite the existence of a valid route towards 2001:DB8::/32. despite the existence of a valid route towards 2001:DB8::/32.
The operational overhead of such a solution is considered high as the The operational overhead of such a solution is considered high, as
operator would have to constantly adapt these access-lists to the operator would have to constantly adapt these access-lists to
accommodate inter-domain routing changes. Moreover, this technique accommodate inter-domain routing changes. Moreover, this technique
lets packets destined to a valid prefix be dropped while they are lets packets destined to a valid prefix be dropped while they are
sent from a neighboring AS that may not know about the policy sent from a neighboring AS that may not know about the policy
conflict, and hence had no means to avoid the creation of unexpected conflict, and hence had no means to avoid the creation of unexpected
traffic flows. For this reason, this technique can be considered traffic flows. For this reason, this technique can be considered
harmful and is thus not recommended for implementation. harmful and is thus not recommended for implementation.
4.2.2. Neighbor-specific forwarding 4.2.2. Neighbor-specific forwarding
An operator can technically ensure that traffic destined to a given An operator can technically ensure that traffic destined to a given
skipping to change at page 13, line 35 skipping to change at page 13, line 35
traffic flow would occur. traffic flow would occur.
Different techniques could provide this functionality; however, their Different techniques could provide this functionality; however, their
technical implementation can be complex to design and operate. An technical implementation can be complex to design and operate. An
operator could, for instance, employ Virtual Routing Forwarding (VRF) operator could, for instance, employ Virtual Routing Forwarding (VRF)
tables (RFC4364 [4]) to store the routes announced to a neighbor and tables (RFC4364 [4]) to store the routes announced to a neighbor and
forward traffic exclusively based on those routes. [2] describes the forward traffic exclusively based on those routes. [2] describes the
use of such an architecture for Internet routing, and provides a use of such an architecture for Internet routing, and provides a
description of its limitations. description of its limitations.
In such an architecture, packets received from a peer would be In such architecture, packets received from a peer would be forwarded
forwarded solely based on the paths that fit the path propagation solely based on the paths that fit the path propagation policy for
policy for that peer, and not based on the global routing table of that peer, and not based on the global routing table of the router.
the router. As a result, a more specific path that would not be As a result, a more specific path that would not be propagated to a
propagated to a peer will not be used to forward a packet from that peer will not be used to forward a packet from that peer, and the
peer, and the unexpected flow will not take place. Packets will be unexpected flow will not take place. Packets will be forwarded based
forwarded based on the policy compliant less specific prefix. on the policy compliant less specific prefix. However, note that an
However, note that an operator must make sure that all their routers operator must make sure that all their routers could support the
could support the potential performance impact of this approach. potential performance impact of this approach.
note that similarly to the solution described in Section 4.1, this Note that similarly to the solution described in Section 4.1, this
approach could create conflicts between AS64502 and AS64501, since approach could create conflicts between AS64502 and AS64501, since
the traffic forwarding performed by AS64502 goes against the policy the traffic forwarding performed by AS64502 goes against the policy
of AS64501. of AS64501.
5. Conclusions 5. Conclusions
In this document, we described how the filtering of more specific In this document, we described how the filtering of more specific
prefixes can potentially create unexpected traffic flows in remote prefixes can potentially create unexpected traffic flows in remote
ASes. We provided examples of scenarios in which unexpected traffic ASes. We provided examples of scenarios in which unexpected traffic
flows are caused by these practices and introduce some techniques for flows are caused by these practices and introduce some techniques for
 End of changes. 16 change blocks. 
46 lines changed or deleted 54 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/