Dear colleagues,
In the attachment, you can find a candidate to become the next version of
the route-leak-detection draft. It has changed that much, that authors
decided to discuss it in the WG before publishing it in the tracker.
The most important question that was reconsidered - what we should be done
with route leaks?
Previously we had hypotheses that certain circumstances we can't drop it
but should set pref to 0. The main reason was the next scenario:
- The prefix must have a single path to Tier1;
- The prefix must not have a less specific prefix with multiple paths
Tier1;
- The leak must affect this single path, so it must be inside single
path to Tier1;
- The prefix must be marked with leak detection signal;
- Immediate ISP that accepts leak must learn it from its customer;
- Immediate ISP that accepts leak must prefer leaked prefix;
- Immediate ISP that accepts leak should not use leak detection;
- Immediate ISP must keep detection signal;
- The upper provider must use leak detection.
In this specific case, the leaked prefix may experience DoS. To fight this
theoretical scenario we suggested to use pref = 0 for leaks that are
learned from customers + additional signal to distribute information.
But such an approach has a tradeoff - if leak affects prefixes that are not
globally visible pref = 0 policy will not stop its propagation. It quite
realistic TE - a common control community is to restrict announcements of
prefixes to selected/all peers, more specifics that are sent only to IXes
etc.
The pref = 0 is also incompatible with future security solutions such as
ASPA and BGPSec - both will require to reject route leaks (pref = 0 can be
abused by mimicking more specific hijacks to route leaks).
So, taking this highly unlikely motivation for pref = 0 and quite a
realistic side effects, it is suggested setting quite simple default
policy: all route leaks must be rejected. With this, we can also drop the
second signal. It also gave us the opportunity to integrate leak detection
and prevention into one community. So, to summarize major changes:
- A single community is used for both route leak prevention, and
detection;
- All route leaks MUST be rejected;
- L is removed since we don't need it in this case.
We haven't reached consensus among the editors yet, that's why it is quite
important to collect broader feedback from the community. I have also
already asked WG chairs to reserve a slot for this discussion during the
next meeting.
PS: It 3.5 pages long, please read it!
--
Best regards,
Alexander Azimov
IDR and SIDR K. Sriram, Ed.
Internet-Draft USA NIST
Intended status: Standards Track A. Azimov, Ed.
Expires: January 9, 2020 Yandex
July 8, 2019
Methods for Detection and Mitigation of BGP Route Leaks
draft-ietf-grow-route-leak-detection-mitigation-02
Abstract
Problem definition for route leaks and enumeration of types of route
leaks are provided in [RFC7908]. This document describes a new well
known large community that gives a way for both route leak prevention
and detection. The configuration process for these community can be
automated with BGP roles that are defined in ietf-idr-bgp-open-policy
draft.
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 January 9, 2020.
Copyright Notice
Copyright (c) 2019 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
Sriram & Azimov Expires January 9, 2020 [Page 1]
Internet-Draft Route Leak Detection and Mitigation July 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 2
3. Community vs Attribute . . . . . . . . . . . . . . . . . . . 3
4. Down Only Community . . . . . . . . . . . . . . . . . . . . . 4
5. Implementation Considerations . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[RFC7908] provides a definition of the route leak problem and
enumerates several types of route leaks. For this document, the
definition that is applied is that a route leak occurs when a route
received from a transit provider or a lateral peer is forwarded
(against commonly used policy) to another transit provider or a
lateral peer. The commonly used policy is that a route received from
a transit provider or a lateral peer MAY be forwarded only to
customers.
This document describes a solution for prevention, detection and
mitigation route leaks which is based on conveying route-leak
detection information in a well known large community. Its
configuration policies MUST be defined according to peering relations
between ISPs. If BGP Roles described in
[I-D.ietf-idr-bgp-open-policy] are configured, community
configuration SHOULD be implemented in code of the routing software.
Described technique can be incrementally deployed. If a group of big
ISPs or/and IXes deploy proposed route marking, then they would be
helping each other by blocking route leaks that can happen between
them.
2. Peering Relationships
As described in [I-D.ietf-idr-bgp-open-policy] there are several
common peering relations between eBGP sessions:
o Provider - sender is a transit provider to neighbor;
Sriram & Azimov Expires January 9, 2020 [Page 2]
Internet-Draft Route Leak Detection and Mitigation July 2019
o Customer - sender is customer of neighbor;
o RS - sender is route server at internet exchange point (IX)
o RS-client - sender is client of RS at internet exchange point (IX)
o Peer - sender and neighbor are peers;
If a route is received from provider, peer or RS-client is MUST
follow 'only down' rule - it MAY be advertised only to customers. If
a route is sent to customer, peer or RS-client it also MUST follow
'only down' rule.
The common technique to implement internal 'only down' rule is to use
BGP communities, but these communities differ from network to network
and can be removed at the receipt. So, we need a standardized
transit signal that will prevent networks from leaking and tell a
remote ISP that receiving prefix violates 'only down' policy, thus
providing a way to stop the propagation of leaked prefixes.
To improve reliability such signal should be set on both sender and
receiver side.
3. Community vs Attribute
In this section will be discussed the advantages and disadvantages of
communities and BGP path attributes for the purpose of route leak
detection.
The transit path attribute seems to be a native way to implement
route leak detection signal. The way BGP process unknown transit
attributes guarantees that such a signal will pass through outdated
BGP implementations without any change. The main disadvantage lays
on a fact that deployment of new BGP attribute requires a software
update which may postpone wide adoption for years.
In opposite, communities don't require a software update. The main
disadvantage of communities is that its usage is highly overloaded.
They already have numerous applications: different types of route
marking, route policy control, blackholing and etc. That's why a
significant number of networks with purpose or accidentally are
removing communities on receipt, even well-known ones.
With the knowledge that route leaks can disrupt Internet connectivity
in the region or even globally the authors believe that it's better
to move forward with route leak detection using communities. The
harm that is done by route leaks isn't a theory - it's constantly
happening events.
Sriram & Azimov Expires January 9, 2020 [Page 3]
Internet-Draft Route Leak Detection and Mitigation July 2019
To nevilate listed disadvantages of community usage, we suggest using
large communities, which have much higher capacity, so it should be
less overloaded. We suggest reserving 4200000000 class for the
purpose of transit well-known communities that MUST not be stripped
on both ingress and egress filters. Also, policy violation is itself
result of absent or improper community configuration. So, the chance
that route-leak-detection community will pass through ISP that
already has configuration mistakes is increased.
While it's not part of this document the described below signal can
be easily translated into BGP path attribute.
4. Down Only Community
This section specifies exact semantics of route-leak-detection
community and its usage. The Down Only (DO) community MUST follow
next semantics:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4200000000 (suggested global administrator) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 (suggested subclass for DO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN who set the community |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the DO Community using a Large Community
[RFC8092].
This community MUST have route policy configuration on both egress
and ingress filters.
The ingress policy MUST follow next procedure:
1. If a route with DO community set is received from Customer or RS-
client - it's a route leak and MUST be rejected. The procedure
halts.
2. If a route with DO community set is received from Peer and DO
value isn't equal to neighbor ASN - it's a route leak and MUST be
rejected. The procedure halts.
Sriram & Azimov Expires January 9, 2020 [Page 4]
Internet-Draft Route Leak Detection and Mitigation July 2019
3. If a route is received from Provider, Peer or RS the DO community
MUST be added with value equal to global administrator ID of the
neighbor (sender).
The egress policy MUST follow next procedure:
1. A route with DO community set MUST not be sent to providers,
peers and RS.
2. If route is sent to customer or peer DO community MUST be added
with value equal to global administrator ID of the sender.
These rules provide support for both route leak prevention and
detection.
5. Implementation Considerations
It was observed that the majority of BGP implementations doesn't
support negative match for communities like a:b:!c. In this case it
is suggested to replace second rule from ingress policy with next
one:
If a route with DO community set is received from Peer and DO value
is equal to neighbor ASN - it's a valid route, otherwise it is a
route leak. The procedure halts.
This rule is based on a weaker assumption that a peer that is doing
marking is also doing filtering. But in return, such rule can be
easily implemented with two consecutive matching rules.
6. Security Considerations
In specific circumstances at the state of partial adoption, route
leak detection mechanism can result in DoS for the victim prefix.
Such a scenario may happen only for prefixes that have a single path
from the originator to Tier1 and which is not covered with less
specific prefixes with multiple paths to Tier1. If, in such
unreliable topology, route leak is injected inside this single path
it may be rejected by upper providers, thus limiting prefix
visibility. While such anomaly is unlikely to happen, such an issue
should be easy to debug, since it directly affects the sequence of
originator's providers.
With the use of BGP community, there is often a concern that the
community propagates beyond its intended perimeter and causes harm
[streibelt]. However, that concern does not apply to the DO
community because it is a transitive community that must propagate as
far as the update goes.
Sriram & Azimov Expires January 9, 2020 [Page 5]
Internet-Draft Route Leak Detection and Mitigation July 2019
7. IANA Considerations
The draft suggests to reserve Global Administrator ID 4200000000 for
transit well-known large community registry. IANA is requested to
register DO community in the well-known large community [RFC8092]
registry.
8. Informative References
[I-D.ietf-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention using Roles in Update and
Open messages", draft-ietf-idr-bgp-open-policy-05 (work in
progress), February 2019.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <https://www.rfc-editor.org/info/rfc7908>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/info/rfc8092>.
[streibelt]
Streibelt et al., F., "BGP Communities: Even more Worms in
the Routing Can", ACM IMC, October 2018,
<https://archive.psg.com//181101.imc-communities.pdf>.
Acknowledgements
The authors wish to thank John Scudder, Susan Hares, Ruediger Volk,
Mat Ford, Greg Skinner for their review and comments.
Contributors
The following people made significant contributions to this document
and should be considered co-authors:
Sriram & Azimov Expires January 9, 2020 [Page 6]
Internet-Draft Route Leak Detection and Mitigation July 2019
Brian Dickson
Independent
Email: brian.peter.dick...@gmail.com
Doug Montgomery
USA National Institute of Standards and Technology
Email: do...@nist.gov
Keyur Patel
Arrcus
Email: ke...@arrcus.com
Andrei Robachevsky
Internet Society
Email: robachev...@isoc.org
Eugene Bogomazov
Qrator Labs
Email: e...@qrator.net
Randy Bush
Internet Initiative Japan
Email: ra...@psg.com
Authors' Addresses
Kotikalapudi Sriram (editor)
USA National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899
United States of America
Email: ksri...@nist.gov
Alexander Azimov (editor)
Yandex
Ulitsa Lva Tolstogo 16
Moscow 119021
Russia
Email: a.e.azi...@gmail.com
Sriram & Azimov Expires January 9, 2020 [Page 7]
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
