draft-ietf-idr-route-leak-detection-mitigation-09.txt   draft-ietf-idr-route-leak-detection-mitigation-10.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: January 3, 2019 Qrator Labs Expires: April 25, 2019 Qrator Labs
July 2, 2018 October 22, 2018
Methods for Detection and Mitigation of BGP Route Leaks Methods for Detection and Mitigation of BGP Route Leaks
draft-ietf-idr-route-leak-detection-mitigation-09 draft-ietf-idr-route-leak-detection-mitigation-10
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 specifies BGP leaks are provided in RFC 7908. This document describes a solution
enhancements that significantly extend its route-leak detection and for detection and mitigation route leaks which is based on conveying
mitigation capabilities. The solution involves each participating AS route-leak protection (RLP) information in a Border Gateway Protocol
setting a route-leak protection (RLP) field in BGP updates. The RLP (BGP) community. The RLP information is carried in a new well-known
fields are carried in a new optional transitive attribute, called BGP transitive BGP community, called the RLP community. The RLP
RLP Attribute. The RLP Attribute helps with detection and mitigation community helps with detection and mitigation of route leaks at ASes
of route leaks at ASes downstream from the leaking AS (in the path of downstream from the leaking AS (in the path of the BGP update). This
BGP update). This is an inter-AS (multi-hop) solution mechanism. is an inter-AS (multi-hop) solution mechanism. This solution
This solution complements the intra-AS (local AS) route-leak complements the intra-AS (local AS) route-leak avoidance solution
avoidance solution that is described in ietf-idr-bgp-open-policy that is described in ietf-idr-bgp-open-policy draft.
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 January 3, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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. Route-Leak Types that the Solution Must Address . . . . . . . 3 2. Mechanisms for Detection and Mitigation of Route Leaks . . . 3
3. Mechanisms for Detection and Mitigation of Route Leaks . . . 5 2.1. Ascertaining Peering Relationship . . . . . . . . . . . . 3
3.1. Ascertaining Peering Relationship . . . . . . . . . . . . 5 2.2. Route-Leak Protection (RLP) Semantics . . . . . . . . . . 4
3.2. Route-Leak Protection (RLP) Field Encoding by Sending 2.2.1. Format of the RLP Community . . . . . . . . . . . . . 5
Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Route Leak Detection Rules and the Ingress Router
3.2.1. BGP RLP Attribute . . . . . . . . . . . . . . . . . . 8 (Receiver) Actions . . . . . . . . . . . . . . . . . . . 6
3.2.2. Carrying RLP Field Values in the BGPsec Flags . . . . 9 2.4. Route Selection Policy . . . . . . . . . . . . . . . . . 6
3.3. Recommended Actions at a Receiving Router for Detection 2.5. Egress Router (Sender) Actions . . . . . . . . . . . . . 7
and Mitigation of Route Leaks . . . . . . . . . . . . . . 10 3. Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
RFC 7908 [RFC7908] provides a definition of the route leak problem, RFC 7908 [RFC7908] provides a definition of the route leak problem,
and enumerates several types of route leaks. This document first and enumerates several types of route leaks. For this document, the
examines which of those route-leak types are detected and mitigated definition that is applied is that a route leak occurs when a route
by the existing Origin Validation (OV) [RFC6811] method. OV received from a transit provider or a lateral peer is forwarded
[RFC6811] and BGPsec path validation [RFC8205] together offer (against commonly used policy) to another transit provider or a
mechanisms to protect against re-originations and hijacks of IP lateral peer. The commonly used policy is that a route received from
prefixes as well as man-in-the-middle (MITM) AS path modifications. a transit provider or a lateral peer may be forwarded "down only" to
Route leaks [RFC7908] are another type of vulnerability in the global customers.
BGP routing system against which OV offers very limited protection.
BGPsec path validation provides cryptographic protection for some
aspects of BGP update messages, but in its current form BGPsec does
not offer any protection against route leaks.
For the types of route leaks enumerated in RFC 7908 [RFC7908], where This document describes a solution for detection and mitigation route
the OV method does not offer a solution, this document specifies BGP leaks which is based on conveying route-leak protection (RLP)
enhancements that significantly extend its route-leak detection and information in a Border Gateway Protocol (BGP) community. The RLP
mitigation capabilities. The solution involves each participating AS information is carried in a new well-known transitive BGP community,
setting a route-leak protection (RLP) field in BGP updates. The RLP called the RLP community. The RLP community helps with detection and
fields are carried in a new optional transitive attribute, called BGP mitigation of route leaks at ASes downstream from the leaking AS (in
RLP Attribute. The RLP Attribute helps with detection and mitigation the path of the BGP update). This is an inter-AS (multi-hop)
of route leaks at ASes downstream from the leaking AS (in the path of solution mechanism. This solution complements the intra-AS (local
BGP update). This is an inter-AS (multi-hop) solution mechanism. AS) route-leak avoidance solution that is described in
This solution complements the intra-AS (local AS) route-leak
avoidance solution that is described in
[I-D.ietf-idr-bgp-open-policy]. [I-D.ietf-idr-bgp-open-policy].
The RLP mechanism is backward compatible with BGP routers that are Previously, an optional transitive BGP RLP Attribute was proposed to
not upgraded to perform RLP. Early adopters would see significant carry the RLP information
benefits. If a group of big ISPs deploy RLP, then they would be [I-D.ietf-idr-route-leak-detection-mitigation]. However, this
helping each other by blocking route leaks originated within one's document proposes a well-known transitive BGP community to carry the
customer cone from propagating into a peer's AS or their customer RLP information, with the intention of promoting faster adoption.
cone.
The inter-AS RLP solution is meant to be initially implemented as an
enhancement of BGP without requiring BGPsec. However, when BGPsec is
deployed in the future, the solution should be incorporated in
BGPsec, enabling cryptographic protection for the RLP fields. That
is one way of securing the solution against malicious route leaks.
2. Route-Leak Types that the Solution Must Address
Referring to the enumeration of route leaks discussed in [RFC7908],
Table 1 summarizes the route-leak detection capability offered by OV
and BGPsec for different types of route leaks.
A detailed explanation of the contents of Table 1 is as follows. It
is readily observed that route leaks of Types 1, 2, 3, and 4 are not
detected by OV or BGPsec in its current form. Clearly, Type 5 route
leak involves re-origination or hijacking, and hence can be detected
by OV. In the case of Type 5 route leak, there would be no existing
ROAs to validate a re-originated prefix or more specific prefix, but
instead a covering ROA would normally exist with the legitimate AS,
and hence the update will be considered Invalid by OV.
+---------------------------------+---------------------------------+
| Type of Route Leak | Current State of Detection |
| | Coverage |
+---------------------------------+---------------------------------+
| Type 1: Hairpin Turn with Full | Neither OV nor BGPsec (in its |
| Prefix | current form) detects Type 1. |
| ------------------------------- | ------------------------------- |
| Type 2: Lateral ISP-ISP-ISP | Neither OV nor BGPsec (in its |
| Leak | current form) detects Type 2. |
| ------------------------------- | ------------------------------- |
| Type 3: Leak of Transit- | Neither OV nor BGPsec (in its |
| Provider Prefixes to Peer | current form) detects Type 3. |
| ------------------------------- | ------------------------------- |
| Type 4: Leak of Peer Prefixes | Neither OV nor BGPsec (in its |
| to Transit Provider | current form) detects Type 4. |
| ------------------------------- | ------------------------------- |
| Type 5: Prefix Re-Origination | OV detects Type 5. |
| with Data Path to Legitimate | |
| Origin | |
| ------------------------------- | ------------------------------- |
| Type 6: Accidental Leak of | For internal prefixes never |
| Internal Prefixes and More | meant to be routed on the |
| Specific Prefixes | Internet, OV helps detect their |
| | leak; they might either have no |
| | covering ROA or have an AS0-ROA |
| | to always filter them. In the |
| | case of accidental leak of more |
| | specific prefixes, OV may offer |
| | some detection due to ROA |
| | maxLength. |
+---------------------------------+---------------------------------+
Table 1: Examination of Route-Leak Detection Capability of Origin
Validation and Current BGPsec Path Validation
In the case of Type 6 leaks involving internal prefixes that are not
meant to be routed in the Internet, they are likely to be detected by
OV. That is because such prefixes might either have no covering ROA
or have an AS0-ROA to always filter them. In the case of Type 6
leaks that are due to accidental leak of more specific prefixes, they
may be detected due to violation of ROA maxLength. BGPsec (i.e.,
path validation) in its current form does not detect Type 6.
However, route leaks of Type 6 are least problematic due to the
following reasons. In the case of leak of more specific prefixes,
the offending AS is itself the legitimate destination of the leaked
more-specific prefixes. Hence, in most cases of this type, the data
traffic is not misrouted. Also, leaked announcements of Type 6 are
short-lived and typically withdrawn quickly following the
announcements. Further, the MaxPrefix limit may kick-in in some
receiving routers and that helps limit the propagation of sometimes
large number of leaked routes of Type 6.
Realistically, BGPsec may take a much longer time being deployed than The inter-AS RLP mechanism described here can be incrementally
OV. Hence, solution proposals for route leaks should consider both deployed. Early adopters would see significant benefits. If a group
scenarios: (A) OV only (without BGPsec) and (B) OV plus BGPsec. of big ISPs deploy RLP, then they would be helping each other by
Assuming an initial scenario A, and based on the above discussion and blocking route leaks originated within one's customer cone from
Table 1, it is evident that the solution method should focus propagating into a peer's AS or their customer cone.
primarily on route leaks of Types 1, 2, 3, and 4.
3. Mechanisms for Detection and Mitigation of Route Leaks 2. Mechanisms for Detection and Mitigation of Route Leaks
There are two considerations for route leaks: (1) Prevention of route There are two considerations for route leaks: (1) Prevention of route
leaks from a local AS [I-D.ietf-idr-bgp-open-policy], and (2) leaks from a local AS [I-D.ietf-idr-bgp-open-policy], and (2)
Detection and mitigation of route leaks in ASes that are downstream Detection and mitigation of route leaks in ASes that are downstream
from the leaking AS (in the path of BGP update). This document from the leaking AS (in the path of BGP update). This document
specifies the latter. specifies the latter.
3.1. Ascertaining Peering Relationship 2.1. Ascertaining Peering Relationship
There are four possible peering relationships (i.e., roles) an AS can There are four possible peering relationships (i.e., roles) an AS can
have with a neighbor AS: (1) Provider: transit-provider for all have with a neighbor AS: (1) Provider: transit-provider for all
prefixes exchanged, (2) Customer: customer for all prefixes prefixes exchanged, (2) Customer: customer for all prefixes
exchanged, (3) Lateral Peer: lateral peer (i.e., non-transit) for all exchanged, (3) Lateral Peer: lateral peer (i.e., non-transit) for all
prefixes exchanged, and (4) Complex: different relationships for prefixes exchanged, and (4) Complex: different relationships for
different sets of prefixes [Luckie]. For the complex case, the different sets of prefixes [Luckie]. For the complex case, the
peering role types provider, customer, or lateral peer apply for peering role types provider, customer, or lateral peer apply for
different non-overlapping sets of prefixes. different non-overlapping sets of prefixes.
skipping to change at page 5, line 50 skipping to change at page 4, line 6
the BGP Role during BGP OPEN messaging (except when the role is the BGP Role during BGP OPEN messaging (except when the role is
complex). It defines a new BGP Role capability, which helps in re- complex). It defines a new BGP Role capability, which helps in re-
confirming the relationship when it is provider, customer, or lateral confirming the relationship when it is provider, customer, or lateral
peer. BGP Role does not replace the OOB communication since it 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 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 message. However, BGP Role provides a means to double check, and if
there is a contradiction detected via the BGP Role messages, then a there is a contradiction detected via the BGP Role messages, then a
Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy]. Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy].
When the BGP relationship information has been correctly exchanged When the BGP relationship information has been correctly exchanged
(i.e., free of contradictions) including the sets of prefixes with including the sets of prefixes with different roles (if complex),
different roles (if complex), then this information SHOULD be used to then this information SHOULD be used to automatically set the role
automatically set the role per-prefix with each peer. For example, per-prefix with each peer. For example, if the local AS's role is
if the local AS's role is Provider with a neighbor AS, then the per- Provider with a neighbor AS, then the per-prefix role is set to
prefix role is set to 'Provider' for all prefixes sent to the 'Provider' for all prefixes sent to the neighbor, and set to
neighbor, and set to 'Customer' for all prefixes received from the 'Customer' for all prefixes received from the neighbor.
neighbor.
Once the per-prefix roles are set, this information is used in the Once the per-prefix roles are set, this information is used in the
RLP solution mechanism that is described in Section 3.2 and RLP solution mechanism that is described in this document.
Section 3.3.
3.2. Route-Leak Protection (RLP) Field Encoding by Sending Router 2.2. Route-Leak Protection (RLP) Semantics
The key principle is that, in the event of a route leak, a receiving The key principle is that, in the event of a route leak, a receiving
router in a transit-provider AS (e.g., referring to Figure 1, ISP2 router in a transit-provider AS (e.g., referring to Figure 1, ISP2
(AS2) router) should be able to detect from the update message that (AS2) router) should be able to detect from the RLP community in the
its customer AS (e.g., AS3 in Figure 1) should not have forwarded the update message that its customer AS (e.g., AS3 in Figure 1) should
update (towards the transit-provider AS). This means that at least not have forwarded the update (towards the transit-provider AS).
one of the ASes in the AS path of the update signaled that it sent Likewise when the update is received from a lateral peer. This means
the update to its customer or lateral peer, but forbade any that at least one of the ASes in the AS path of the update put RLP
subsequent 'Up' (customer to provider) or 'Lateral' (peer to peer) information in RLP community to indicate that it sent the update to
forwarding. This signaling is achieved by a Route-Leak Protection its customer or lateral peer, but forbade any subsequent 'Up'
(RLP) field as described below. (customer to provider) or 'Lateral' (peer to peer) forwarding.
/\ /\ /\ /\
\ route-leak(P)/ \ route-leak(P)/
\ propagated / \ propagated /
\ / \ /
+------------+ peer +------------+ +------------+ peer +------------+
______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> ______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
/ ------------+ prefix(P) +------------+ route-leak(P) / ------------+ prefix(P) +------------+ route-leak(P)
| prefix | \ update /\ \ propagated | prefix | \ update /\ \ propagated
\ (P) / \ / \ \ (P) / \ / \
------- prefix(P) \ / \ ------- prefix(P) \ / \
update \ / \ update \ / \
\ /route-leak(P) \/ \ /route-leak(P) \/
\/ / \/ /
+---------------+ +---------------+
| customer(AS3) | | customer(AS3) |
+---------------+ +---------------+
Figure 1: Illustration of the basic notion of a route leak. Figure 1: Illustration of the basic notion of a route leak.
* Design A: The RLP information contained in the RLP community consists of one or
two AS numbers (ASNs) and has the following semantics:
For route-leak detection and mitigation, the Route Leak Protection
(RLP) field value MUST be set as follows:
o Insert the public registered local AS number and RLP = 0 when BGP
UPDATE is forwarded to a transit provider,
o Insert the public registered local AS number and RLP = 1 when BGP
UPDATE is forwarded to a customer or lateral peer.
* Design B:
For route-leak detection and mitigation, the Route Leak Protection
(RLP) field value MUST be set as follows:
o Do not insert anything when BGP UPDATE is forwarded to a transit
provider,
o Insert the public registered local AS number when BGP UPDATE is 1. Down Only (DO) indication: ASN of the most recent RLP-aware AS in
forwarded to a customer or lateral peer. the path to assert that it sent the update to a customer or
lateral peer;
Note: Design A requires all participating ASes in the path to 2. Leak detected (L) indication: ASN of the first RLP-aware AS in
indicate the direction in which the BGP UPDATE is sent. On the other the path to assert that it forwarded the route from a customer or
hand, Design B requires participating ASes to insert their AS number lateral peer despite detecting a leak (to avoid unreachability).
only when the BGP UPDATE is sent to a customer or lateral peer.
After discussion in the WG, one of the designs will be finalized. It
will be discussed if the extra information provided in Design A adds
value for route leak detection and mitigation.
Note: In the rest of this document, by "RLP is set" it is meant that If the RLP community is present in an update, it will always contain
RLP = 1 for one or more ASes in the AS path (in Design A), or, that a single DO. However, L need not be always present. (Note: The bits
the RLP Attribute (with one or more AS numbers in it) is present (in designated to carry L may be always present along with a DO, except
Design B). Further, in the context of either design, "RLP includes that a default value (all zeros) is carried in L when no AS in the
AS X" means that "RLP is set" by AS X which is in the path. The current AS path needed to assert L.) Once an AS asserts L (Leak
intent of setting RLP is that the neighbor AS or any receiving AS detected) by inserting its ASN value, it MUST not be changed
along the subsequent AS path SHOULD NOT forward the UPDATE 'Up' subsequently as the update propagates. But the ASN value in DO (Down
towards its transit-provider AS or laterally towards its peer AS. Only) is changeable along the AS path per its definition above.
The RLP fields are set on a per prefix basis. This is because some Design assumption 1: Operators desire to avoid unreachability. So, a
peering relations between neighbors can be complex (see Section 3.1). design assumption here is that in the absence of an alternative
route, an AS may select and forward a route that is detected to be a
leak. (Note: This is the reason Leak detected (L) indication is part
of the design.)
Either Design A or B (described above) works for detection and Design assumption 2: An AS that is RLP-aware (i.e., implements the
mitigation of route leaks of Types 1, 2, 3, and 4 which are the focus RLP solution in this document) MUST also implement an intra-AS
here (see Section 3.3). solution for route leak avoidance in the local AS. The latter
solution uses an intra-AS signaling mechanism (see
[I-D.ietf-idr-bgp-open-policy], Section 3.7 of [RLP-Discussion]). By
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].
An AS MUST NOT rewrite/reset the values set by any preceding ASes in 2.2.1. Format of the RLP Community
their respective RLP fields.
The RLP encoding MUST be carried in BGP-4 [RFC4271] updates in a new The format of the RLP community using a single Large Community is
BGP optional transitive attribute (see Section 3.2.1). In BGPsec, it shown in Figure 2.
must be carried in the Flags field (see Section 3.2.2).
In partial deployment, there may be eBGP routers in the AS path that 0 1 2 3
are not upgraded and hence do not participate in RLP. However, the 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
RLP mechanism is backward compatible. Participating ASes can detect +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and mitigate route leaks while ASes not upgraded might remain | Global Administrator (IANA assigned for RLP) |
vulnerable. If big ISPs deploy RLP, then they would be helping each +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
other by not allowing route leaks originated within one's customer | Local Data Part 1 = DO (ASN value) |
cone to propagate into another's AS or their customer cone. This +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
accords significant benefit to early adopters. | Local Data Part 2 = L (ASN value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1. BGP RLP Attribute Figure 2: Format of the RLP Community using a Large Community
[RFC8092].
The BGP RLP Attribute is a new BGP optional transitive attribute. 2.3. Route Leak Detection Rules and the Ingress Router (Receiver)
The attribute type code for the RLP Attribute is to be assigned by Actions
IANA. The length field of this attribute is 2 octets.
* RLP Attribute for Design A: A received BGP update is determined to be a route leak if:
The value field of the RLP Attribute is defined as a set of one or 1. if L is present in the update;
more pairs of ASN (4 octets) and RLP (one octet) fields as described
below (Figure 2).
+-----------------------+ -\ 2. else (L is absent), the update is received from a customer and DO
| ASN: N | | is present;
+-----------------------+ > (Most recently added)
| RLP: N | |
+-----------------------+ -/
...........
+-----------------------+ -\
| ASN: 1 | |
+-----------------------+ > (Least recently added)
| RLP: 1 | |
+-----------------------+ -/
Figure 2: BGP RLP Attribute format. 3. else (L is absent), the update is received from a lateral peer
and DO is present that is not the lateral peer's ASN.
The RLP Attribute value is a sequence of these two components (see Note: Here by "L is present" we mean that its value is not the
Figure 2): default value (all zeros) but is a proper ASN. Effectively "L is
absent" if its value is the default value.
ASN: Four octets encoding the public registered AS number of a BGP In steps 2 and 3 above, the ingress router (receiver) MUST add L =
speaker. local ANS. Doing this prior to the best path selection process is
necessary. Also, if the route is selected as best path, then L is
already set correctly before the egress router (sender) acts on it.
RLP Field: One octet encoding the RLP Field bits. The value of the 2.4. Route Selection Policy
RLP Field octet can be 0 (decimal) or 1 (decimal) as described above
in Section 3.2.1. Its usage will be further discussed in subsequent
sections.
If all ASes in the AS_PATH of a route are upgraded to participate in Minimum Default Policy: Whenever there is a choice between a customer
RLP, then the ASNs in the RLP TLV in Figure 2 will correspond one-to- route and a provider route that are both detected to be leaks (L is
one with sequence of ASes in the AS_PATH (excluding prepends). If present), then lower the LocalPref to X (TBD by operator) for each of
some ASes do not participate, then one or more {ASN, RLP} tuples may them. Then shortest path criterion would typically make the customer
be missing in the RLP Attribute relative to the AS_PATH. route preferred. (Note: This would help mitigate any possibility of
persistent oscillation; see slide #7 in [sriram1].)
* RLP Attribute for Design B: Generalized Minimum Default Policy: Whenever there is a choice
between multiple routes (customer/peer/provider) and each is detected
to be a leak (L is present), then lower the LocalPref to X TBD by
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.)
The value field of the RLP Attribute is defined as a sequence of one 2.5. Egress Router (Sender) Actions
or more ASN (4 octets) fields as described below (Figure 3).
+-----------------------+ After best path selection has been performed, a sender MUST perform
| ASN: N | (Most recently added) the following RLP-related actions on the update to be propagated:
+-----------------------+
| ASN: N-1 |
+-----------------------+
...........
+-----------------------+
| ASN: 2 |
+-----------------------+
| ASN: 1 | (Least recently added)
+-----------------------+
Figure 3: BGP RLP Attribute format. 1. When propagating a route originated by the local AS to a customer
or lateral peer, add DO = local ASN;
Thus, the RLP Attribute value is a sequence public registered AS 2. Else, when propagating a route that already includes a DO (i.e.,
numbers (see Figure 3). The ASNs of only the participating was received with a DO) to a customer or lateral peer, replace
(upgraded) ASes that sent the BGP UPDATE to a customer or lateral the DO value with the local ASN.
peer appear in the RLP Attribute.
3.2.2. Carrying RLP Field Values in the BGPsec Flags 3. Pseudo Code
In BGPsec-enabled routers that are also performing RLP, the RLP [Begin: receiver action for route leak detection]
encoding MUST be accommodated in the existing Flags field in BGPsec
updates. The Flags field is part of the Secure_Path Segment in
BGPsec updates [RFC8205]. One Flags field (one octet in size) is
available for each AS hop, and currently only the first bit is used
in BGPsec. So, there are 7 bits that are currently unused in the
Flags field. One of these bits can be designated for the RLP field
value (see Section 3.2.1). This bit is set to 0 when the RLP Field
value is 0 and set to 1 when the RLP Field value is 1. Since the
BGPsec protocol specification requires a sending AS to include the
Flags field in the data that are signed over, the RLP field for each
hop (since it would be part of the Flags field as described) will be
protected under the sending AS's signature.
3.3. Recommended Actions at a Receiving Router for Detection and {Comment: This precedes route selection policy.}
Mitigation of Route Leaks
Route Leak Detection: if received route includes L, then save the route in RIB-in as is;
When a customer route has at least one or more RLP fields set (to else (L is absent), if route is received from a customer and DO is
indicate 'do not propagate to provider or peer') by any AS(es) preset, then add L = local ASN;
preceding the customer AS, then the route MUST be marked as route
leak. The same applies in the case of a peer route also.
Route Leak Mitigation: else (L is absent), if route is received from a lateral peer and
DO is present that is not the lateral peer's ASN, then add L =
local ASN
For the most part, route leak mitigation policy can be set locally by {Comment: "Route does not include L" or "L is absent" only if L is
a network operator. However, the following rules MUST be included in either literally absent or has the default (all zeros) value.}
any route leak mitigation policy. These rules ensure stable route
convergence and avoid the possibility of persistent route
oscillations (see Section 3.1 in the route leak solution discussion
document [RLP-Discussion] for an explanation).
o Rule 1: If ISP A receives a route r1 from customer AS C and [End: receiver action for route leak detection]
another route r2 from provider (or peer) AS B (for the same
prefix), and both routes r1 and r2 contain AS C and AS X (any X
not equal to C) in the path and also contain [X] in their RLP
Attributes, then prioritize the customer (AS C) route over the
provider (or peer) route.
o Rule 2: If ISP A receives a route r1 from peer AS C and another ----------------------------------------------------------
route r2 from provider AS B (for the same prefix), and both routes
r1 and r2 contain AS C and AS X (any X not equal to C) in the path
and also contain [X] in their RLP Attributes, then prioritize the
peer (AS C) route over the provider (AS B) route.
Including the rules stated above, the RECOMMENDED route leak [Begin: route selection policy]
mitigation policy is as follows:
1. Given a choice between a customer route versus a provider (or for each route that includes L, lower the LocalPref to X (TBD);
peer) route, apply best path selection policy*
* if no route leak is detected in the customer route, then {*Comment: E.g., best path selection based on LocalPref first and
prioritize the customer over the provider (or peer); then shortest path.}
* else (i.e., when route leak is detected in the customer route) [End: route selection policy]
and the conditions of Rule 1 apply, then too prioritize the
customer over the provider (or peer);
* else (i.e., when route leak is detected in the customer route ----------------------------------------------------------
and the conditions of Rule 1 DO NOT apply), then prioritize
the provider (or peer) over the customer.
2. Given a choice between a peer route versus a provider route, [Begin: sender action]
* if no route leak is detected in the peer route, then {Comment: RLP (includes DO and L or just DO) is a *transitive* BGP
prioritize the peer over the provider; community and should propagate globally.}
* else (i.e., when route leak is detected in the peer route) and when propagating a route originated by local AS to a customer or
the conditions of Rule 2 apply, then too prioritize the peer lateral peer, add DO = local ASN;
over the provider;
* else (i.e., when route leak is detected in the peer route and when propagating a route that includes a DO (i.e., was received
the conditions of Rule 2 DO NOT apply), then prioritize the with a DO) to a customer or lateral peer, replace the DO value
provider over the peer. with the local ASN;
In the case of choosing between a peer route and a provider route, [End: sender action]
network operators MAY apply a policy (different from the above) that
they deem appropriate in their operating environment.
4. Security Considerations 4. Security Considerations
The Route-Leak Protection (RLP) field requires cryptographic With the use of BGP community, there is often a concern that the
protection to prevent malicious route leaks. In the future, in community propagates beyond its intended perimeter and causes harm
conjunction with BGPsec deployment, the RLP field will be included in [streibelt]. However, that concern does not apply to the RLP
the Flags field in the Secure_Path Segment in BGPsec updates. So, community because it is a transitive community that must propagate as
the cryptographic security mechanisms in BGPsec will also apply to far as the update goes.
the RLP field. The reader is therefore directed to the security
The proposed Route-Leak Protection (RLP) information carried in the
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]. considerations provided in [RFC8205].
5. IANA Considerations 5. IANA Considerations
IANA is requested to register a new optional, transitive attribute, IANA is requested to register RLP in the well-known Large Community
named "Route Leak Protection (RLP) Attribute" in the BGP Path [RFC8092] registry (need help to clarify this). IANA is requested to
Attributes registry. The attribute type code is TBD. The reference allocate a new Global Administrator ID for the RLP community (Large
for this new attribute is this document (i.e., the RFC that replaces Community) (see Figure 2 in this document). Note that BGP Path
this draft). The length field of this attribute is 2 octets, and the Attribute value for Large Community is 32 (IANA allocated) [RFC8092].
length of the value field of this attribute is variable (see
Figure 2) in Section 3.2.1 of this document).
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
6.2. Informative References 6.2. Informative References
[draft-dickson-sidr-route-leak-solns] [draft-dickson-sidr-route-leak-solns]
skipping to change at page 12, line 19 skipping to change at page 9, line 25
Internet Draft (expired), March 2012, Internet Draft (expired), March 2012,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-dickson-sidr-route-leak-solns-01>. 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-03 (work in Open messages", draft-ietf-idr-bgp-open-policy-03 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-idr-route-leak-detection-mitigation]
Sriram, K. and A. Azimov, "Methods for Detection and
Mitigation of BGP Route Leaks", draft-ietf-idr-route-leak-
detection-mitigation-09 (work in progress), July 2018.
[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
kc. claffy, "AS Relationships, Customer Cones, and kc. claffy, "AS Relationships, Customer Cones, and
Validation", IMC 2013, October 2013, Validation", IMC 2013, October 2013,
<http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>. <http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>. February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[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,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/info/rfc8092>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RLP-Discussion] [RLP-Discussion]
Sriram (Ed.), K., "Design Discussion of Route Leaks Sriram (Ed.), K., "Design Discussion of Route Leaks
Solution Methods", Work in Progress, draft-sriram-idr- Solution Methods", Work in Progress, draft-sriram-idr-
route-leak-solution-design-discussion-00, July 2018. 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 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 Acknowledgements
The authors wish to thank Jared Mauch, Jeff Haas, Job Snijders, The authors wish to thank John Scudder and Susan Hares for their
Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy review and comments.
Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes George, Job
Snijders, Chris Morrow, Sandy Murphy, Danny McPherson, and Eric
Osterweil for comments, suggestions, and critique. The authors are
thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim 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
 End of changes. 65 change blocks. 
349 lines changed or deleted 235 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/