draft-ietf-grow-route-leak-detection-mitigation-00.txt   draft-ietf-grow-route-leak-detection-mitigation-01.txt 
IDR and SIDR K. Sriram, Ed. IDR and SIDR K. Sriram, Ed.
Internet-Draft USA NIST Internet-Draft USA NIST
Intended status: Standards Track A. Azimov, Ed. Intended status: Standards Track A. Azimov, Ed.
Expires: October 21, 2019 Yandex Expires: January 26, 2020 Yandex
April 19, 2019 July 25, 2019
Methods for Detection and Mitigation of BGP Route Leaks Methods for Detection and Mitigation of BGP Route Leaks
draft-ietf-grow-route-leak-detection-mitigation-00 draft-ietf-grow-route-leak-detection-mitigation-01
Abstract Abstract
Problem definition for route leaks and enumeration of types of route Problem definition for route leaks and enumeration of types of route
leaks are provided in RFC 7908. This document describes a solution leaks are provided in [RFC7908]. This document describes a new well-
for detection and mitigation route leaks which is based on conveying known Large Community that provides a way for route leak prevention,
route-leak protection (RLP) information in a Border Gateway Protocol detection, and mitigation. The configuration process for this
(BGP) community. The RLP information is carried in a new well-known Community can be automated with the methodology for setting BGP roles
transitive BGP community, called the RLP community. The RLP
community helps with detection and mitigation of route leaks at ASes
downstream from the leaking AS (in the path of the BGP update). This
is an inter-AS (multi-hop) solution mechanism. This solution
complements the intra-AS (local AS) route-leak avoidance solution
that is described in ietf-idr-bgp-open-policy draft. that is described in ietf-idr-bgp-open-policy draft.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 October 21, 2019. This Internet-Draft will expire on January 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mechanisms for Detection and Mitigation of Route Leaks . . . 3 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 2
2.1. Ascertaining Peering Relationship . . . . . . . . . . . . 3 3. Community vs Attribute . . . . . . . . . . . . . . . . . . . 3
2.2. Route-Leak Protection (RLP) Semantics . . . . . . . . . . 4 4. Down Only Community . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Format of the RLP Community . . . . . . . . . . . . . 5 4.1. Route Leak Mitigation . . . . . . . . . . . . . . . . . . 5
2.3. Route Leak Detection Rules and the Ingress Router 4.2. Only Marking . . . . . . . . . . . . . . . . . . . . . . 6
(Receiver) Actions . . . . . . . . . . . . . . . . . . . 6 5. Implementation Considerations . . . . . . . . . . . . . . . . 6
2.4. Route Selection Policy . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
2.5. Egress Router (Sender) Actions . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
3. Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
RFC 7908 [RFC7908] provides a definition of the route leak problem, [RFC7908] provides a definition of the route leak problem and
and enumerates several types of route leaks. For this document, the enumerates several types of route leaks. For this document, the
definition that is applied is that a route leak occurs when a route definition that is applied is that a route leak occurs when a route
received from a transit provider or a lateral peer is forwarded received from a transit provider or a lateral peer is forwarded
(against commonly used policy) to another transit provider or a (against commonly used policy) to another transit provider or a
lateral peer. The commonly used policy is that a route received from lateral peer. The commonly used policy is that a route received from
a transit provider or a lateral peer may be forwarded "down only" to a transit provider or a lateral peer MAY be forwarded only to
customers. customers.
This document describes a solution for detection and mitigation route This document describes a solution for prevention, detection and
leaks which is based on conveying route-leak protection (RLP) mitigation route leaks which is based on conveying route-leak
information in a Border Gateway Protocol (BGP) community. The RLP detection information in a well-known BGP Large Community. The
information is carried in a new well-known transitive BGP community, configuration process for the Large Community MUST be defined
called the RLP community. The RLP community helps with detection and according to peering relations between ISPs. This process can be
mitigation of route leaks at ASes downstream from the leaking AS (in automated with the methodology for setting BGP roles that is
the path of the BGP update). This is an inter-AS (multi-hop) described in [I-D.ietf-idr-bgp-open-policy].
solution mechanism. This solution complements the intra-AS (local
AS) route-leak avoidance solution that is described in
[I-D.ietf-idr-bgp-open-policy].
Previously, an optional transitive BGP RLP Attribute was proposed to
carry the RLP information (in earlier versions of this document).
However, this updated document proposes a well-known transitive BGP
community to carry the RLP information, with the intention of
promoting faster adoption.
The inter-AS RLP mechanism described here can be incrementally The techniques described in this document can be incrementally
deployed. Early adopters would see significant benefits. If a group deployed. If a group of big ISPs and/or Internet Exchanges (IXes)
of big ISPs deploy RLP, then they would be helping each other by deploy the proposed techniques, then they would be helping each other
blocking route leaks originated within one's customer cone from by blocking route leaks that can happen between them.
propagating into a peer's AS or their customer cone.
2. Mechanisms for Detection and Mitigation of Route Leaks 2. Peering Relationships
There are two considerations for route leaks: (1) Prevention of route As described in [I-D.ietf-idr-bgp-open-policy] there are several
leaks from a local AS [I-D.ietf-idr-bgp-open-policy], and (2) common peering relations between eBGP neighbors:
Detection and mitigation of route leaks in ASes that are downstream
from the leaking AS (in the path of BGP update). This document
specifies the latter.
2.1. Ascertaining Peering Relationship o Provider - sender is a transit provider of the neighbor;
There are four possible peering relationships (i.e., roles) an AS can o Customer - sender is a customer of the neighbor;
have with a neighbor AS: (1) Provider: transit-provider for all
prefixes exchanged, (2) Customer: customer for all prefixes
exchanged, (3) Lateral Peer: lateral peer (i.e., non-transit) for all
prefixes exchanged, and (4) Complex: different relationships for
different sets of prefixes [Luckie]. For the complex case, the
peering role types provider, customer, or lateral peer apply for
different non-overlapping sets of prefixes.
Operators rely on some form of out-of-band (OOB) (i.e., external to o Route Server (RS) - sender is route server at an internet exchange
BGP) communication to exchange information about their peering (IX)
relationship, AS number, interface IP address, etc. If the
relationship is complex, the OOB communication also includes the sets
of prefixes for which they have different roles.
[I-D.ietf-idr-bgp-open-policy] introduces a method of re-confirming
the BGP Role during BGP OPEN messaging (except when the role is
complex). It defines a new BGP Role capability, which helps in re-
confirming the relationship when it is provider, customer, or lateral
peer. BGP Role does not replace the OOB communication since it
relies on the OOB communication to set the role type in the BGP OPEN
message. However, BGP Role provides a means to double check, and if
there is a contradiction detected via the BGP Role messages, then a
Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy].
When the BGP relationship information has been correctly exchanged o RS-client - sender is client of an RS at an IX
including the sets of prefixes with different roles (if complex),
then this information SHOULD be used to automatically set the role
per-prefix with each peer. For example, if the local AS's role is
Provider with a neighbor AS, then the per-prefix role is set to
'Provider' for all prefixes sent to the neighbor, and set to
'Customer' for all prefixes received from the neighbor.
Once the per-prefix roles are set, this information is used in the o Peer - sender and neighbor are lateral (non-transit) peers;
RLP solution mechanism that is described in this document.
2.2. Route-Leak Protection (RLP) Semantics If a route is received from a provider, peer or RS-client, it MUST
follow the 'down only' rule, i.e., it MAY be advertised only to
customers. If a route is sent to a customer, peer or RS-client, it
also MUST follow the 'down only' rule at each subsequent AS in the AS
path.
The key principle is that, in the event of a route leak, a receiving A standardized transitive route-leak detection signal is needed that
router in a transit-provider AS (e.g., referring to Figure 1, ISP2 will prevent Autonomous Systems (ASes) from leaking and also inform a
(AS2) router) should be able to detect from the RLP community in the remote ISP (or AS) in the AS path that a received route violates
update message that its customer AS (e.g., AS3 in Figure 1) should 'down only' policy. This signal would facilitate a way to stop the
not have forwarded the update (towards the transit-provider AS). propagation of leaked prefixes.
Likewise when the update is received from a lateral peer. This means
that at least one of the ASes in the AS path of the update put RLP
information in RLP community to indicate that it sent the update to
its customer or lateral peer, but forbade any subsequent 'Up'
(customer to provider) or 'Lateral' (peer to peer) forwarding.
/\ /\ To improve reliability and cover for non-participating preceding
\ route-leak(P)/ neighbor, the signal should be set on both receiver and sender sides.
\ propagated /
\ /
+------------+ peer +------------+
______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
/ ------------+ prefix(P) +------------+ route-leak(P)
| prefix | \ update /\ \ propagated
\ (P) / \ / \
------- prefix(P) \ / \
update \ / \
\ /route-leak(P) \/
\/ /
+---------------+
| customer(AS3) |
+---------------+
Figure 1: Illustration of the basic notion of a route leak. 3. Community vs Attribute
The RLP information contained in the RLP community consists of one or This section presents a brief discussion of the advantages and
two AS numbers (ASNs) and has the following semantics: disadvantages of communities and BGP path attributes for the purpose
of route leak detection.
1. Down Only (DO) indication: ASN of the most recent RLP-aware AS in A transitive path attribute is a native way to implement the route-
the path to assert that it sent the update to a customer or leak detection signal. Based on the way BGP protocol works, the use
lateral peer; of a transitive attribute makes it more certain that the route-leak
detection signal would pass unaltered through non-participating
(i.e., not updated) BGP routers. The main disadvantage of this
approach is that the deployment of a new BGP attribute requires a
software update in router OS which may delay wide adoption for years.
2. Leak detected (L) indication: ASN of the first RLP-aware AS in On the other hand, BGP communities do not require a router OS update.
the path to assert that it forwarded the route from a customer or The potential disadvantage of using a Community for the route-leak
lateral peer despite detecting a leak (to avoid unreachability). detection signal is that it is more likely to be dropped somewhere
along the way in the AS path. Currently, the use of BGP Communities
is somewhat overloaded. BGP Communities are already used for
numerous applications: different types of route marking, route policy
control, black-holing, etc. It is observed that some ASes seem to
purposefully or accidentally remove transitive communities on
receipt, sometimes well-known ones. Perhaps this issue may be
mitigated with strong policy guidance related to the handling of
Communities.
If the RLP community is present in an update, it will always contain Due to frequently occurring regional and global disruptions in
a single DO. However, L need not be always present. (Note: The bits Internet connectivity, it is critical to move forward with a solution
designated to carry L may be always present along with a DO, except that is viable in the near term. That solution would be route leak
that a default value (all zeros) is carried in L when no AS in the detection using BGP Community.
current AS path needed to assert L.) Once an AS asserts L (Leak
detected) by inserting its ASN value, it MUST not be changed
subsequently as the update propagates. But the ASN value in DO (Down
Only) is changeable along the AS path per its definition above.
Design assumption 1: Operators desire to avoid unreachability. So, a Large Communities have much higher capacity, and therefore they are
design assumption here is that in the absence of an alternative likely to be less overloaded. Hence, Large Community is proposed to
route, an AS may select and forward a route that is detected to be a be used for route-leak detection. This document suggests reserving
leak. (Note: This is the reason Leak detected (L) indication is part <TBD1> class for the purpose of transitive well-known Large
of the design.) Communities that MUST not be stripped on ingress or egress.
Design assumption 2: An AS that is RLP-aware (i.e., implements the While it is not part of this document, the route-leak detection
RLP solution in this document) MUST also implement an intra-AS signal described here can also be carried in a BGP path attribute,
solution for route leak avoidance in the local AS. The latter and the same prevention and mitigation techniques as described here
solution uses an intra-AS signaling mechanism (see would apply. The authors are pursuing a separate internet draft in
[I-D.ietf-idr-bgp-open-policy], Section 3.7 of [RLP-Discussion]). By the IDR WG on that approach.
doing this, the AS locally prevents the leaking of routes learned
from a transit provider or lateral peer to another transit provider
or lateral peer. Why this is critical to the overall solution is
made clear in slides 7 and 8 of [sriram2].
2.2.1. Format of the RLP Community 4. Down Only Community
The format of the RLP community using a single Large Community is This section specifies the semantics of route-leak-detection
shown in Figure 2. Community and its usage. This Community is given the specific name
Down Only (DO) Community. The DO Community is carried in a BGP Large
Community with a format as shown in Figure 1.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (IANA assigned for RLP) | | TBD1 (class for well-known transit communities) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 1 = DO (ASN value) | | TBD2 (subclass for DO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 2 = L (ASN value) | | ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the RLP Community using a Large Community Figure 1: Format of the DO Community using a Large Community
[RFC8092]. [RFC8092].
2.3. Route Leak Detection Rules and the Ingress Router (Receiver) The authors studied different options for route leak mitigation. The
Actions main options considered are (1) drop detected route leaks and (2)
deprioritize detected route leaks. It can be demonstrated that the
A received BGP update is determined to be a route leak if: loose mode that uses deprioritization is not safe. Traffic
Engineering (TE) technique which limit prefix visibility are quite
1. if L is present in the update; common. It may happen that a more specific TE prefix is sent only to
downstream ASes or to IX(es)/selected peers, and a control Community
2. else (L is absent), the update is received from a customer and DO is used to restrict its propagation. If such a more specific prefix
is present; is leaked, deprioritization will not stop such a route leak from
propagating. In addition, propagation of leaked prefixes based on
3. else (L is absent), the update is received from a lateral peer deprioritization may result in priority loops leading to BGP wedgies
and DO is present that is not the lateral peer's ASN. [RFC4264] or even persistent route oscillations.
Note: Here by "L is present" we mean that its value is not the
default value (all zeros) but is a proper ASN. Effectively "L is
absent" if its value is the default value.
In steps 2 and 3 above, the ingress router (receiver) MUST add L = So, the only truly safe way to implement route leak mitigation is to
local ANS. Doing this prior to the best path selection process is drop detected route leaks. The ingress and egress policies
necessary. Also, if the route is selected as best path, then L is corresponding to 'drop detected route leaks' is described in
already set correctly before the egress router (sender) acts on it. Section 4.1. This policy SHOULD be used as a default behavior.
2.4. Route Selection Policy Nevertheless, early adopters might want to deploy only the signaling
and perhaps use it only for diagnostics before applying any route
leak mitigation policy. They are also encouraged to use slightly
limited marking, which is described in Section 4.2.
Minimum Default Policy: Whenever there is a choice between a customer 4.1. Route Leak Mitigation
route and a provider route that are both detected to be leaks (L is
present), then lower the LocalPref to X (TBD by operator) for each of
them. Then shortest path criterion would typically make the customer
route preferred. (Note: This would help mitigate any possibility of
persistent oscillation; see slide #7 in [sriram1].)
Generalized Minimum Default Policy: Whenever there is a choice This section describes the eBGP ingress and egress policies that MUST
between multiple routes (customer/peer/provider) and each is detected be used to perform route leak prevention, detection and mitigation
to be a leak (L is present), then lower the LocalPref to X TBD by using the DO Community.
operator) for each of them. Then apply shortest path criterion.
(Note: Some network operators may find this inadequate; see scenarios
#3 and #6 in slides #14 and #16, respectively, in [sriram2]. But
they may locally modify their policy while respecting the basic
principle.)
2.5. Egress Router (Sender) Actions The ingress policy MUST use the following procedure:
After best path selection has been performed, a sender MUST perform 1. If a route with DO Community set (i.e., DO is attached) is
the following RLP-related actions on the update to be propagated: received from a Customer or RS-client, then it is a route leak
and MUST be rejected. The procedure halts.
1. When propagating a route originated by the local AS to a customer 2. If a route with DO Community set is received from Peer (non-
or lateral peer, add DO = local ASN; transit) and DO value is not equal to the sending neighbor's ASN,
then it is a route leak and MUST be rejected. The procedure
halts.
2. Else, when propagating a route that already includes a DO (i.e., 3. If a route is received from a Provider, Peer or RS, then the DO
was received with a DO) to a customer or lateral peer, replace Community MUST be added with a value equal to the sending
the DO value with the local ASN. neighbor's ASN.
3. Pseudo Code The egress policy MUST use the following procedure:
[Begin: receiver action for route leak detection] 1. A route with DO Community set MUST not be sent to Providers,
Peers, and RS.
{Comment: This precedes route selection policy.} 2. If a route is sent to a Customer or Peer, then the DO Community
MUST be added with a value equal to the ASN of the sender.
if received route includes L, then save the route in RIB-in as is; The above procedures comprehensively provide route-leak prevention,
detection and mitigation. Policy consisting of these procedures
SHOULD be used as a default behavior.
else (L is absent), if route is received from a customer and DO is 4.2. Only Marking
preset, then add L = local ASN;
else (L is absent), if route is received from a lateral peer and This section describes eBGP ingress and egress marking policies that
DO is present that is not the lateral peer's ASN, then add L = MUST be used if an AS is not performing route-leak mitigation (i.e.,
local ASN dropping detected route leaks) as described in Section 4.1, but wants
to use only marking with DO Community. The slightly limited DO
marking (compared to that in Section 4.1) described below guarantees
that this DO marking will not limit the leak detection opportunities
for subsequent ASes in the AS path.
{Comment: "Route does not include L" or "L is absent" only if L is The ingress policy MUST use the following procedure:
either literally absent or has the default (all zeros) value.}
[End: receiver action for route leak detection] 1. If a route with DO Community set is received from a Customer or
RS-client, then it is a route leak. The procedure halts.
---------------------------------------------------------- 2. If a route with DO Community set is received from a Peer and DO
value is not equal to the sending neighbor's ASN, then it is a
route leak. The procedure halts.
[Begin: route selection policy] 3. If a route is received from a Provider, Peer or RS, then the DO
Community MUST be added with value equal to the sending
neighbor's ASN.
for each route that includes L, lower the LocalPref to X (TBD); The egress policy MUST use the following procedure:
apply best path selection policy*
{*Comment: E.g., best path selection based on LocalPref first and 1. If a route is sent to a Customer or RS-client, then the DO
then shortest path.} Community MUST be added with value equal to the ASN of the
sender.
[End: route selection policy] 2. If DO Community is not set and the route is sent to a Peer, then
the DO Community MUST be added with value equal to the ASN of the
sender.
---------------------------------------------------------- These above procedures specify setting DO signal in a way that can be
used to evaluate the potential impact of route leak mitigation policy
before deploying strict dropping of detected route leaks.
[Begin: sender action] 5. Implementation Considerations
{Comment: RLP (includes DO and L or just DO) is a *transitive* BGP It was observed that the majority of BGP implementations does not
community and should propagate globally.} support negative match for communities like a:b:!c. Considering that
it is suggested to replace the second rule from ingress policy with
the following:
when propagating a route originated by local AS to a customer or If a route with DO Community set is received from a Peer and DO value
lateral peer, add DO = local ASN; is equal to the sending neighbor's ASN, then it is a valid route,
otherwise it is a route leak. The procedure halts.
when propagating a route that includes a DO (i.e., was received This rule is based on a weaker assumption that a peer that is doing
with a DO) to a customer or lateral peer, replace the DO value marking is also doing filtering (dropping detected leaks). That is
with the local ASN; why networks that do not follow the route leak mitigation policy in
Section 4.1 MUST carefully follow marking rules described in
Section 4.2.
[End: sender action] 6. Security Considerations
4. Security Considerations In specific circumstances in a state of partial adoption, route leak
mitigation mechanism can result in Denial of Service (DoS) for the
victim prefix. Such a scenario may happen only for a prefix that has
a single path from the originator to a Tier-1 ISP and only when the
prefix is not covered with a less specific prefix with multiple paths
to the Tier-1 ISP. If, in such unreliable topology, route leak is
injected somewhere inside this single path, then it may be rejected
by upper layer providers in the path, 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 With the use of BGP Community, there is often a concern that the
community propagates beyond its intended perimeter and causes harm Community propagates beyond its intended perimeter and causes harm
[streibelt]. However, that concern does not apply to the RLP [streibelt]. However, that concern does not apply to the DO
community because it is a transitive community that must propagate as Community because it is a transitive Community that must propagate as
far as the update goes. far as the update goes.
The proposed Route-Leak Protection (RLP) information carried in the 7. IANA Considerations
RLP community can benefit from cryptographic protection to prevent
abuse by malicious actors in the AS path. In the future, if there is
BGPsec deployment, the RLP information can be encoded in the Flags
field in the Secure_Path Segment in BGPsec updates [RFC8205]. So,
the cryptographic security mechanisms in BGPsec can also secure the
RLP information. The reader is directed to the security
considerations provided in [RFC8205].
5. IANA Considerations
IANA is requested to register RLP in the well-known Large Community
[RFC8092] registry (need help to clarify this). IANA is requested to
allocate a new Global Administrator ID for the RLP community (Large
Community) (see Figure 2 in this document). Note that BGP Path
Attribute value for Large Community is 32 (IANA allocated) [RFC8092].
6. References
6.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
6.2. Informative References The draft suggests to reserve a Global Administrator ID <TBD1> for
transitive well-known Large Community registry. IANA is requested to
register a subclass <TBD2> for DO Community in this registry.
[draft-dickson-sidr-route-leak-solns] 8. Informative References
Dickson, B., "Route Leaks -- Proposed Solutions", IETF
Internet Draft (expired), March 2012,
<https://tools.ietf.org/html/
draft-dickson-sidr-route-leak-solns-01>.
[I-D.ietf-idr-bgp-open-policy] [I-D.ietf-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention using Roles in Update and Sriram, "Route Leak Prevention using Roles in Update and
Open messages", draft-ietf-idr-bgp-open-policy-05 (work in Open messages", draft-ietf-idr-bgp-open-policy-06 (work in
progress), February 2019. progress), July 2019.
[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
kc. claffy, "AS Relationships, Customer Cones, and
Validation", IMC 2013, October 2013,
<http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, DOI 10.17487/RFC4264, November 2005,
February 2015, <https://www.rfc-editor.org/info/rfc7454>. <https://www.rfc-editor.org/info/rfc4264>.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <https://www.rfc-editor.org/info/rfc7908>. 2016, <https://www.rfc-editor.org/info/rfc7908>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute", I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017, RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/info/rfc8092>. <https://www.rfc-editor.org/info/rfc8092>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[RLP-Discussion]
Sriram (Ed.), K., "Design Discussion of Route Leaks
Solution Methods", Work in Progress, draft-sriram-idr-
route-leak-solution-discussion-00, July 2018,
<https://tools.ietf.org/html/
draft-sriram-idr-route-leak-solution-discussion-00>.
[sriram1] Sriram et al., K., "Route Leaks Solution Merger of RLP and
eOTC Drafts", Presented at the IDR Working Group Meeting,
IETF-102, Montreal, July 2018,
<https://datatracker.ietf.org/meeting/102/materials/
slides-102-idr-sessb-route-leaks-merged-solution-00>.
[sriram2] Sriram et al., K., "Solution for Route Leaks Using BGP
Communities", Authors Team Discussion Slides, October
2018, <https://www.nist.gov/sites/default/files/
documents/2018/10/22/rlp_using_bgp_community-v4.pdf>.
[streibelt] [streibelt]
Streibelt et al., F., "BGP Communities: Even more Worms in Streibelt et al., F., "BGP Communities: Even more Worms in
the Routing Can", ACM IMC, October 2018, the Routing Can", ACM IMC, October 2018,
<https://archive.psg.com//181101.imc-communities.pdf>. <https://archive.psg.com//181101.imc-communities.pdf>.
Acknowledgements Acknowledgements
The authors wish to thank John Scudder, Susan Hares, and Ruediger The authors wish to thank John Scudder, Susan Hares, Ruediger Volk,
Volk for their review and comments. Mat Ford, Greg Skinner for their review and comments.
Contributors Contributors
The following people made significant contributions to this document The following people made significant contributions to this document
and should be considered co-authors: and should be considered co-authors:
Brian Dickson Brian Dickson
Independent Independent
Email: brian.peter.dickson@gmail.com Email: brian.peter.dickson@gmail.com
skipping to change at page 11, line 41 skipping to change at page 9, line 17
Kotikalapudi Sriram (editor) Kotikalapudi Sriram (editor)
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899 Gaithersburg, MD 20899
United States of America United States of America
Email: ksriram@nist.gov Email: ksriram@nist.gov
Alexander Azimov (editor) Alexander Azimov (editor)
Yandex Yandex
Moscow Ulitsa Lva Tolstogo 16
Moscow 119021
Russia Russia
Email: a.e.azimov@gmail.com Email: a.e.azimov@gmail.com
 End of changes. 70 change blocks. 
304 lines changed or deleted 213 lines changed or added

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