draft-ietf-idr-route-leak-detection-mitigation-05.txt   draft-ietf-idr-route-leak-detection-mitigation-06.txt 
IDR and SIDR K. Sriram IDR and SIDR K. Sriram
Internet-Draft D. Montgomery Internet-Draft D. Montgomery
Intended status: Standards Track US NIST Intended status: Standards Track US NIST
Expires: July 13, 2017 B. Dickson Expires: September 7, 2017 B. Dickson
K. Patel K. Patel
Arrcus Arrcus
A. Robachevsky A. Robachevsky
Internet Society Internet Society
January 9, 2017 March 6, 2017
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-05 draft-ietf-idr-route-leak-detection-mitigation-06
Abstract Abstract
[I-D.ietf-grow-route-leak-problem-definition] provides a definition RFC 7908 provides a definition of the route leak problem, and also
of the route leak problem, and also enumerates several types of route enumerates several types of route leaks. This document first
leaks. This document first examines which of those route-leak types examines which of those route-leak types are detected and mitigated
are detected and mitigated by the existing origin validation (OV) by the existing origin validation (OV) [RFC 6811]. It is recognized
[RFC 6811]. It is recognized that OV offers a limited detection and that OV offers a limited detection and mitigation capability against
mitigation capability against route leaks. This document specifies route leaks. This document specifies enhancements that significantly
enhancements that significantly extend the route-leak prevention, extend the route-leak prevention, detection, and mitigation
detection, and mitigation capabilities of BGP. One solution capabilities of BGP. One solution component involves intra-AS
component involves carrying a per-hop route-leak protection (RLP) messaging from ingress router to egress router using a BGP Community
field in BGP updates. The RLP field is proposed to be carried in a or Attribute. This intra-AS messaging prevents the AS from causing
new optional transitive attribute, called BGP RLP attribute. The route leaks. Another solution component involves carrying a per-hop
solution is meant to be initially implemented as an enhancement of route-leak protection (RLP) field in BGP updates. The RLP fields are
BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. proposed to be carried in a new optional transitive attribute, called
However, when BGPsec is deployed in the future, the solution can be BGP RLP attribute. The RLP attribute helps with detection and
incorporated in BGPsec, enabling cryptographic protection for the RLP mitigation of route leaks at ASes downstream from the leaking AS.
field. That would be one way of implementing the proposed solution
in a secure way. The document also includes a stopgap method for
detection and mitigation of route leaks for an intermediate phase
when OV is deployed but BGP protocol on the wire is unchanged.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2017.
This Internet-Draft will expire on July 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 3 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 4
3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4 3. Do Origin Validation and BGPsec Assist in Route-Leak
3.1. Route-Leak Protection (RLP) Field Encoding by Sending Detection? . . . . . . . . . . . . . . . . . . . . . . . . . 4
Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Mechanisms for Prevention, Detection and Mitigation of Route
3.1.1. BGP RLP Attribute . . . . . . . . . . . . . . . . . . 8 Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Carrying RLP Flag Values in the BGPsec Flags . . . . 9 4.1. Ascertaining Peering Relationship . . . . . . . . . . . . 6
3.2. Intra-AS Messaging for Route Leak Prevention . . . . . . 9 4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging 7
3.3. Recommended Actions at a Receiving Router for Detection 4.2.1. Non-Transitive BGP Community for Intra-AS Messaging . 7
of Route Leaks . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Non-Transitive BGP pRLP Attribute for Intra-AS
3.4. Possible Actions at a Receiving Router for Mitigation . . 11 Messaging . . . . . . . . . . . . . . . . . . . . . . 8
4. Stopgap Solution when Only Origin Validation is Deployed . . 11 4.3. Route-Leak Protection (RLP) Field Encoding by Sending
5. Design Rationale and Discussion . . . . . . . . . . . . . . . 12 Router . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Is route-leak solution without cryptographic protection a 4.3.1. BGP RLP Attribute . . . . . . . . . . . . . . . . . . 10
serious attack vector? . . . . . . . . . . . . . . . . . 12 4.3.2. Carrying RLP Field Values in the BGPsec Flags . . . . 11
5.2. Combining results of route-leak detection, OV and BGPsec 4.4. Recommended Actions at a Receiving Router for Detection
validation for path selection decision . . . . . . . . . 14 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 11
5.3. Are there cases when valley-free violations can be 4.5. Possible Actions at a Receiving Router for Mitigation . . 12
considered legitimate? . . . . . . . . . . . . . . . . . 14 5. Stopgap Solution when Only Origin Validation is Deployed . . 12
5.4. Comparison with other methods, routing security BCP . . . 15 6. Design Rationale and Discussion . . . . . . . . . . . . . . . 13
5.5. Per-Hop RLP Flags or Single RLP Flag per Update? . . . . 15 6.1. Is route-leak solution without cryptographic protection a
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 serious attack vector? . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.2. Combining results of route-leak detection, OV and BGPsec
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 validation for path selection decision . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Are there cases when valley-free violations can be
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 considered legitimate? . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 17 6.4. Comparison with other methods (routing security BCPs) . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 6.5. Per-Hop RLP Field or Single RLP Flag per Update? . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[I-D.ietf-grow-route-leak-problem-definition] provides a definition [RFC7908] provides a definition of the route leak problem, and also
of the route leak problem, and also enumerates several types of route enumerates several types of route leaks. This document first
leaks. This document first examines which of those route-leak types examines which of those route-leak types are detected and mitigated
are detected and mitigated by the existing Origin Validation (OV) by the existing Origin Validation (OV) [RFC6811] method. OV and
[RFC6811] method. OV and BGPsec path validation BGPsec path validation [I-D.ietf-sidr-bgpsec-protocol] together offer
[I-D.ietf-sidr-bgpsec-protocol] together offer mechanisms to protect mechanisms to protect against re-originations and hijacks of IP
against re-originations and hijacks of IP prefixes as well as man-in- prefixes as well as man-in-the-middle (MITM) AS path modifications.
the-middle (MITM) AS path modifications. Route leaks (see Route leaks (see [RFC7908] and references cited at the back) are
[I-D.ietf-grow-route-leak-problem-definition] and references cited at another type of vulnerability in the global BGP routing system
the back) are another type of vulnerability in the global BGP routing against which OV offers only partial protection. BGPsec (i.e. path
system against which OV offers only partial protection. BGPsec (i.e. validation) provides cryptographic protection for some aspects of BGP
path validation) provides cryptographic protection for some aspects update messages, but in its current form BGPsec doesn't offer any
of BGP update messages, but in its current form BGPsec doesn't offer protection against route leaks.
any protection against route leaks.
For the types of route leaks enumerated in For the types of route leaks enumerated in [RFC7908], where the OV
[I-D.ietf-grow-route-leak-problem-definition], where the OV method method does not offer a solution, this document specifies
does not offer a solution, this document specifies enhancements that enhancements that significantly extend the route-leak prevention,
significantly extend the route-leak prevention, detection, and detection, and mitigation capabilities of BGP. One solution
mitigation capabilities of BGP. One solution component involves component involves intra-AS messaging from ingress router to egress
carrying a per-hop route-leak protection (RLP) field in BGP updates. router using a BGP Community or Attribute. This intra-AS messaging
The RLP field is proposed be carried in a new optional transitive prevents the AS from causing route leaks. Another solution component
attribute, called BGP RLP attribute. The solution is meant to be involves carrying a per-hop route-leak protection (RLP) field in BGP
initially implemented as an enhancement of BGP without requiring updates. The RLP fields are proposed to be carried in a new optional
BGPsec. However, when BGPsec is deployed in the future, the solution transitive attribute, called BGP RLP attribute. The RLP attribute
can be incorporated in BGPsec, enabling cryptographic protection for helps with detection and mitigation of route leaks at ASes downstream
the RLP field. That would be one way of implementing the proposed from the leaking AS.
solution in a secure way. It is not claimed that the solution
detects all possible types of route leaks but it detects several The solution is meant to be initially implemented as an enhancement
types, especially considering some significant route-leak occurrences of BGP without requiring BGPsec. However, when BGPsec is deployed in
that have been observed in recent years. The document also includes the future, the solution can be incorporated in BGPsec, enabling
a stopgap method (in Section 4) for detection and mitigation of route cryptographic protection for the RLP field. That would be one way of
leaks for an intermediate phase when OV is deployed but BGP protocol implementing the proposed solution in a secure way. It is not
on the wire is unchanged. claimed that the solution detects all possible types of route leaks
but it detects several types, especially considering some significant
route-leak occurrences that have been observed in recent years. The
document also includes a stopgap method (in Section 5) for detection
and mitigation of route leaks for an intermediate phase when OV is
deployed but BGP protocol on the wire is unchanged.
2. Related Prior Work 2. Related Prior Work
The basic idea and mechanism embodied in the proposed solution is A mechanism embodied in the proposed solution is based on setting an
based on setting an attribute in BGP route announcement to manage the attribute in BGP route announcement to manage the transmission/
transmission/receipt of the announcement based on the type of receipt of the announcement based on the type of neighbor (e.g.
neighbor (e.g. customer, transit provider, etc.). Documented prior customer, transit provider, etc.). Documented prior work related to
work related to said basic idea and mechanism dates back to at least said basic idea and mechanism dates back to at least the 1980's.
the 1980's. Some examples of prior work are: (1) Information flow Some examples of prior work are: (1) Information flow rules described
rules described in [proceedings-sixth-ietf] (see pp. 195-196); (2) in [proceedings-sixth-ietf] (see pp. 195-196); (2) Link Type
Link Type described in [RFC1105-obsolete] (see pp. 4-5); (3) described in [RFC1105-obsolete] (see pp. 4-5); (3) Hierarchical
Hierarchical Recording described in Recording described in [draft-kunzinger-idrp-ISO10747-01] (see
[draft-kunzinger-idrp-ISO10747-01] (see Section 6.3.1.12). The Section 6.3.1.12). The problem of route leaks and possible solution
problem of route leaks and possible solution mechanisms based on mechanisms based on encoding peering-link type information, e.g. P2C
encoding peering-link type information, e.g. P2C (i.e. Transit- (i.e. Transit-Provider to Customer), C2P (i.e. Customer to Transit-
Provider to Customer), C2P (i.e. Customer to Transit-Provider), p2p Provider), p2p (i.e. peer to peer) etc., in BGPsec updates and
(i.e. peer to peer) etc., in BGPsec updates and protecting the same protecting the same under BGPsec path signatures have been discussed
under BGPsec path signatures have been discussed in IETF SIDR WG at in IETF SIDR WG at least since 2011.
least since 2011. [draft-dickson-sidr-route-leak-solns] attempted to [draft-dickson-sidr-route-leak-solns] attempted to describe these
describe these mechanisms in a BGPsec context. The draft expired in mechanisms in a BGPsec context. The draft expired in 2012.
2012. [draft-dickson-sidr-route-leak-solns] defined neighbor [draft-dickson-sidr-route-leak-solns] defined neighbor relationships
relationships on a per link basis, but in the current document the on a per link basis, but in the current document the relationship is
relationship is encoded per prefix, as routes for prefixes with encoded per prefix, as routes for prefixes with different peering
different business models are often sent over the same link. Also relationships may be sent over the same link. Also
[draft-dickson-sidr-route-leak-solns] proposed a second signature [draft-dickson-sidr-route-leak-solns] proposed a second signature
block for the link type encoding, separate from the path signature block for the link type encoding, separate from the path signature
block in BGPsec. By contrast, in the current document when BGPsec- block in BGPsec. By contrast, in the current document when BGPsec-
based solution is considered, cryptographic protection is provided based solution is considered, cryptographic protection is provided
for Route-Leak Protection (RLP) encoding using the same signature for Route-Leak Protection (RLP) encoding using the same signature
block as that for path signatures (see Section 3.1). block as that for path signatures (see Section 4.3.2).
3. Mechanisms for Detection and Mitigation of Route Leaks 3. Do Origin Validation and BGPsec Assist in Route-Leak Detection?
Referring to the enumeration of route leaks discussed in Referring to the enumeration of route leaks discussed in [RFC7908],
[I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the Table 1 summarizes the route-leak detection capability offered by OV
route-leak detection capability offered by OV and BGPsec for and BGPsec for different types of route leaks. (Note: Prefix
different types of route leaks. (Note: Prefix filtering is not filtering is not considered here in this table. Please see
considered here in this table. Please see Section 4.) Section 5.)
A detailed explanation of the contents of Table 1 is as follows. It 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 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 detected by OV or BGPsec in its current form. Clearly, Type 5 route
leak involves re-origination or hijacking, and hence can be detected 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 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, but instead ROAs to validate a re-originated prefix or more specific, but instead
a covering ROA would normally exist with the legitimate AS, and hence a covering ROA would normally exist with the legitimate AS, and hence
the update will be considered Invalid by OV. the update will be considered Invalid by OV.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Type 6 are short-lived and typically withdrawn quickly following the Type 6 are short-lived and typically withdrawn quickly following the
announcements. Further, the MaxPrefix limit may kick-in in some announcements. Further, the MaxPrefix limit may kick-in in some
receiving routers and that helps limit the propagation of sometimes receiving routers and that helps limit the propagation of sometimes
large number of leaked routes of Type 6. large number of leaked routes of Type 6.
Realistically, BGPsec may take a much longer time being deployed than Realistically, BGPsec may take a much longer time being deployed than
OV. Hence solution proposals for route leaks should consider both OV. Hence solution proposals for route leaks should consider both
scenarios: (A) OV only (without BGPsec) and (B) OV plus BGPsec. scenarios: (A) OV only (without BGPsec) and (B) OV plus BGPsec.
Assuming an initial scenario A, and based on the above discussion and Assuming an initial scenario A, and based on the above discussion and
Table 1, it is evident that the solution method should focus Table 1, it is evident that the solution method should focus
primarily on route leaks of Types 1, 2, 3, and 4. Section 3.1 and primarily on route leaks of Types 1, 2, 3, and 4.
Section 3.3 describe a simple addition to BGP that facilitates
detection of route leaks of Types 1, 2, 3, and 4. The simple
addition involves a per-hop Route-Leak Protection (RLP) field. The
RLP fields are carried in an optional transitive attribute in BGP,
called BGP RLP attribute. When BGPsec is deployed, the RLP field
will be accommodated in the existing Flags field (see
[I-D.ietf-sidr-bgpsec-protocol]) which is cryptographically protected
under path signatures. Section 3.2 describes intra-AS messaging and
common practice for route leak prevention in major ISPs' networks.
3.1. Route-Leak Protection (RLP) Field Encoding by Sending Router 4. Mechanisms for Prevention, Detection and Mitigation of Route Leaks
There are two considerations for route leaks: (1) Prevention of route
leaks from a local AS, and (2) Detection and mitigation of route
leaks in ASes that are downstream from the leaking AS.
In Section 4.1, the method of ascertaining peering relationship per
prefix is described. Section 4.2 describes intra-AS messaging
methods for prevention of route leaks from local AS. Section 4.3 and
Section 4.4 describe a simple addition to BGP that facilitates
detection and mitigation of route leaks of Types 1, 2, 3, and 4 (see
Section 3) at an downstream AS from the leaking AS.
4.1. Ascertaining Peering Relationship
There are four possible peering relationships (i.e. roles) an AS can
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 [I-D.ymbk-idr-bgp-open-policy] [Luckie].
On a per-prefix basis, the peering role types simplify to provider,
customer, or lateral peer.
Operators rely on some form of out-of-band (OOB) (i.e. external to
BGP) communication to exchange information about their peering
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.ymbk-idr-bgp-open-policy] introduces a method of confirming the
BGP Role during BGP OPEN messaging. It defines a new BGP Role
capability, which helps in re-confirming the relationship. 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.ymbk-idr-bgp-open-policy].
When the BGP relationship information has been correctly exchanged
(i.e. free of contradictions) including the sets of prefixes with
different roles (if complex), then this information SHOULD be used to
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.
4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging
Note: The intra-AS messaging for route leak prevention can be done
using non-transitive BGP Community or Attribute. Both options are
described below; one of them will be chosen after IDR working group
consensus is established.
4.2.1. Non-Transitive BGP Community for Intra-AS Messaging
The following procedure (or similar) for intra-AS messaging (i.e.
between ingress and egress routers) for prevention of route leaks is
a fairly common practice used by large ISPs. (Note: This information
was gathered from discussions on the NANOG mailing list
[Nanog-thread-June2016] as well as through private discussions with
operators of large ISP networks.)
Routes are tagged on ingress to an AS with communities for origin,
including the type of eBGP peer it was learned from (customer,
provider or lateral peer), geographic location, etc. The community
attributes are carried across the AS with the routes. Routes that
the AS originates directly are tagged with similar origin communities
when they are redistributed into BGP from static, IGP, etc. These
communities are used along with additional logic in route policies to
determine which routes are to be announced to which eBGP peers and
which are to be dropped. Route policy is applied to eBGP sessions
based on what set of routes they should receive (transit, full
routes, internal-only, default-only, etc.). In this process, the
ISP's AS also ensures that routes learned from a transit-provider or
a lateral peer (i.e. non-transit) at an ingress router are not leaked
at an egress router to another transit-provider or lateral peer.
Additionally, in many cases, ISP network operators' outbound policies
require explicit matches for expected communities before passing
routes. This helps ensure that that if an update has made it into
the routing table (i.e. RIB) but has missed its ingress community
tagging (due to a missing/misapplied ingress policy), it will not be
inadvertently leaked.
The above procedure (or a simplified version of it) is also
applicable when an AS consists of a single eBGP router. It is
recommended that all AS operators SHOULD implement the procedure
described above (or similar that is appropriate for their network) to
prevent route leaks that they have direct control over.
4.2.2. Non-Transitive BGP pRLP Attribute for Intra-AS Messaging
It is possible to use an optional non-transitive BGP Attribute
instead of the Community described above for intra-AS messaging for
route leak prevention. The following description would be used in
case the IDR working group decides on using a BGP Attribute.
A new optional non-transitive BGP Attribute called Preventive Route
Leak Protection (pRLP) is used. The attribute type code for the pRLP
attribute is to be assigned by IANA. The length of this attribute is
0 as it is used only as a flag.
Ingress (receiving) router action: The decision to set or not set the
pRLP flag is made by a receiving router upon a route ingress. The
flag is set when the route is received from a provider or a lateral
peer. The flag is not set when the route is received from a
customer. When the relationship is complex, the flag is set based on
the per-prefix peering role information discussed in Section 4.1.
Egress (sending) router action: A sending router is allowed to send a
route without the pRLP flag to any neighbor (transit-provider,
customer, lateral peer). However, if the pRLP flag is present, then
the route MUST NOT be sent to a transit-provider or a lateral peer.
An AS that follows the above set of receiver (ingress) and sender
(egress) actions, prevents itself from causing route leaks.
4.3. Route-Leak Protection (RLP) Field Encoding by Sending Router
This section, Section 4.4 and Section 4.5 describe methods of
detection and mitigation of route leaks in an AS downstream from the
leaking AS.
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 update message that
its customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the its customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the
update (towards the transit-provider AS). This means that at least update (towards the transit-provider AS). This means that at least
one of the ASes in the AS path of the update has indicated that it one of the ASes in the AS path of the update has indicated that it
sent the update to its customer or lateral (i.e. non-transit) peer, sent the update to its customer or lateral (i.e. non-transit) peer,
but forbade any subsequent 'Up' forwarding (i.e. from a customer AS but forbade any subsequent 'Up' forwarding (i.e. from a customer AS
to its transit-provider AS). For this purpose, a Route-Leak to its transit-provider AS). For this purpose, a Route-Leak
skipping to change at page 7, line 34 skipping to change at page 9, line 34
For the purpose of route-leak detection and mitigation proposed in For the purpose of route-leak detection and mitigation proposed in
this document, the RLP field value SHOULD be set to one of two values this document, the RLP field value SHOULD be set to one of two values
as follows: as follows:
o 0: This is the default value (i.e. "nothing specified"), o 0: This is the default value (i.e. "nothing specified"),
o 1: This is the 'Do not Propagate Up or Lateral' indication; sender o 1: This is the 'Do not Propagate Up or Lateral' indication; sender
indicating that the route SHOULD NOT be forwarded 'Up' towards a indicating that the route SHOULD NOT be forwarded 'Up' towards a
transit-provider AS or to a lateral (i.e. non-transit) peer AS. transit-provider AS or to a lateral (i.e. non-transit) peer AS.
The RLP indications SHOULD be set on a per prefix and per neighbor AS The RLP indications SHOULD be set on a per prefix basis. This is
basis. This is because updates for prefixes with different business because some peering relations between neighbors can be complex (see
models are often sent over the same link between ASes. Section 4.1). Further, the RLP indications are set on a per-hop
(i.e. per AS) basis.
There are two different scenarios when a sending AS SHOULD set value There are two different scenarios when a sending AS SHOULD set value
1 in the RLP field: (a) when sending the update to a customer AS, and 1 in the RLP field: (a) when sending the update to a customer AS, and
(b) when sending the update to a lateral peer (i.e. non-transit) AS. (b) when sending the update to a lateral peer (i.e. non-transit) AS.
In essence, in both scenarios, the intent of RLP = 1 is that the In essence, in both scenarios, the intent of RLP = 1 is that the
neighbor AS and any receiving AS along the subsequent AS path SHOULD neighbor AS and any receiving AS along the subsequent AS path SHOULD
NOT forward the update 'Up' towards its (receiving AS's) transit- NOT forward the update 'Up' towards its (receiving AS's) transit-
provider AS or laterally towards its peer (i.e. non-transit) AS. provider AS or laterally towards its peer (i.e. non-transit) AS.
When sending an update 'Up' to a transit-provider AS, the RLP When sending an update 'Up' to a transit-provider AS, the RLP
encoding SHOULD be set to the default value of 0. When a sending AS encoding SHOULD be set to the default value of 0. When a sending AS
sets the RLP encoding to 0, it is indicating to the receiving AS that sets the RLP encoding to 0, it is indicating to the receiving AS that
the update can be propagated in any direction (i.e. towards transit- the update can be propagated in any direction (i.e. towards transit-
provider, customer, or lateral peer). This two-state specification provider, customer, or lateral peer).
in the RLP field works for detection and mitigation of route leaks of
Types 1, 2, 3, and 4 which are the focus here (see Section 3.3 and
Section 3.4).
An AS SHOULD NOT rewrite/reset the values set by any preceding ASes The two-state specification in the RLP field (as described above)
in their respective RLP fields. works for detection and mitigation of route leaks of Types 1, 2, 3,
and 4 which are the focus here (see Section 4.4 and Section 4.5).
An AS MUST NOT rewrite/reset the values set by any preceding ASes in
their respective RLP fields.
The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271]
updates in a new BGP optional transitive attribute (see updates in a new BGP optional transitive attribute (see
Section 3.1.1). And it SHOULD be carried in BGPsec in the Flags Section 4.3.1). In BGPsec, it SHOULD be carried in the Flags field
field (see Section 3.1.2). (see Section 4.3.2).
3.1.1. BGP RLP Attribute 4.3.1. BGP RLP Attribute
The BGP RLP attribute is a new BGP optional transitive attribute. The BGP RLP attribute is a new BGP optional transitive attribute.
The attribute type code for the RLP attribute is to be assigned by The attribute type code for the RLP attribute is to be assigned by
IANA. The value field of the RLP attribute is defined as a set of IANA. The length field of this attribute is 2 octets. The value
one or more RLP TLVs (Type, Length, Value) as described below: field of the RLP attribute is defined as a set of one or more pairs
of ASN (4 octets) and RLP (one octet) fields as described below
(Figure 2).
+-----------------------+ -\ +-----------------------+ -\
| ASN: N | | | ASN: N | |
+-----------------------+ > (Most recently added) +-----------------------+ > (Most recently added)
| RLP: N | | | RLP: N | |
+-----------------------+ -/ +-----------------------+ -/
........... ...........
+-----------------------+ -\ +-----------------------+ -\
| ASN: 1 | | | ASN: 1 | |
+-----------------------+ > (Least recently added) +-----------------------+ > (Least recently added)
| RLP: 1 | | | RLP: 1 | |
+-----------------------+ -/ +-----------------------+ -/
Figure 2: RLP TLV format. Figure 2: BGP RLP Attribute format.
RLP TLV has these two components: The RLP Attribute value is a sequence of these two components (see
Figure 2):
ASN: Four octets encoding the public registered AS number of a BGP ASN: Four octets encoding the public registered AS number of a BGP
speaker. speaker.
RLP Flag: One octet encoding the RLP Flag bits. Usage of these flag RLP Field: One octet encoding the RLP Field bits. The value of the
bits was described above and will be further discussed in subsequent RLP Field octet can be 0 (decimal) or 1 (decimal) as described above
in Section 4.3.1. Its usage will be further discussed in subsequent
sections. sections.
If all ASes in the AS_PATH of a route are upgraded to participate in If all ASes in the AS_PATH of a route are upgraded to participate in
RLP, then the ASNs in the RLP TLV in Figure 2 will correspond one-to- RLP, then the ASNs in the RLP TLV in Figure 2 will correspond one-to-
one with sequence of ASes in the AS_PATH (excluding prepends). If one with sequence of ASes in the AS_PATH (excluding prepends). If
some ASes do not participate, then one or more {ASN, RLP} tuples may some ASes do not participate, then one or more {ASN, RLP} tuples may
be missing in the RLP TLV relative to the AS_PATH. be missing in the RLP attribute relative to the AS_PATH.
3.1.2. Carrying RLP Flag Values in the BGPsec Flags 4.3.2. Carrying RLP Field Values in the BGPsec Flags
In BGPsec enabled routers, the RLP encoding SHOULD be accommodated in In BGPsec enabled routers, the RLP encoding SHOULD be accommodated in
the existing Flags field in BGPsec updates. The Flags field is part the existing Flags field in BGPsec updates. The Flags field is part
of the Secure_Path Segment in BGPsec updates of the Secure_Path Segment in BGPsec updates
[I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags
field is available for each AS hop, and currently only the first bit field 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 is used in BGPsec. So there are 7 bits that are currently unused in
the Flags field. Two (or more if needed) of these bits can be the Flags field. One of these bits can be designated for the RLP
designated for the RLP field. Since the BGPsec protocol field value (see Section 4.3.1). This bit can be set to 0 when the
specification requires a sending AS to include the Flags field in the RLP Field value is 0 and set to 1 when the RLP Field value is 1.
data that are signed over, the RLP field for each hop (assuming it Since the BGPsec protocol specification requires a sending AS to
would be part of the Flags field) will be protected under the sending include the Flags field in the data that are signed over, the RLP
AS's signature. field for each hop (assuming it would be part of the Flags field as
described) will be protected under the sending AS's signature.
3.2. Intra-AS Messaging for Route Leak Prevention
The following procedure (or similar) for intra-AS messaging (i.e.
between ingress and egress routers) for prevention of route leaks is
a fairly common practice used by large ISPs. (Note: This information
was gathered from discussions on the NANOG mailing list
[Nanog-thread-June2016] as well as through private discussions with
operators of large ISP networks.)
Routes are tagged on ingress to an AS with communities for origin,
including the type of eBGP peer it was learned from (customer,
transit-provider or peer), geographic location, etc. The community
attributes are carried across the AS with the routes. Routes that
the AS originates directly are tagged with similar origin communities
when they are redistributed into BGP from static, IGP, etc. These
communities are used along with additional logic in route policies to
determine which routes are to be announced to which eBGP peers and
which are to be dropped. Route policy is applied to eBGP sessions
based on what set of routes they should receive (transit, full
routes, internal-only, default-only, etc.). In this process, the
ISP's AS also ensures that routes learned from a transit-provider or
a lateral peer (i.e. non-transit) at an ingress router are not leaked
at an egress router to another transit-provider or lateral peer.
Additionally, in many cases, ISP network operators' outbound policies
require explicit matches for expected communities before passing
routes. This helps ensure that that if an update has made it into
the routing table (i.e. RIB) but has missed its ingress community
tagging (due to a missing/misapplied ingress policy), it will not be
inadvertently leaked.
The above procedure (or a simplified version of it) is also
applicable when an AS consists of a single eBGP router. It is
recommended that all AS operators SHOULD implement the procedure
described above (or similar that is appropriate for their network) to
prevent route leaks that they have direct control over.
In the above described common practice, the IPS's ingress and egress
routers primarily rely on pre-configured knowledge of the peer type
for each of its eBGP peers. However, as an additional measure of
route-leak alertness, the ingress router SHOULD examine the RLP value
set by the eBGP peer from which the route is received. If said eBGP
peer is a customer (for the route), then the RLP value is expected to
be set to 0 (see Section 3.1). And if said eBGP peer is a transit-
provider or lateral peer, then the RLP field is expected to be set to
1. If the observed RLP value differs from the expectation, then the
event SHOULD be logged, and said eBGP peer SHOULD be notified.
3.3. Recommended Actions at a Receiving Router for Detection of Route 4.4. Recommended Actions at a Receiving Router for Detection of Route
Leaks Leaks
An example set of receiver actions that work to detect and mitigate The following receiver algorithm is RECOMMENDED for detecting route
route leaks of Types 1, 2, 3, and 4 are provided here. This example leaks:
algorithm serves as a proof of concept. However, other receiver
algorithms or procedures can be designed (based on the same sender
specification as in Section 3.1) and may perform with greater
efficacy, and are by no means excluded.
A recommended receiver algorithm for detecting a route leak is as
follows:
A receiving router SHOULD mark an update as a 'Route Leak' if ALL of A receiving router MUST mark an update as a 'Route Leak' if ALL of
the following conditions hold true: the following conditions hold true:
1. The update is received from a customer or lateral peer AS. 1. The update is received from a customer or lateral peer AS.
2. The update has the RLP field set to 1 (i.e. 'Do not Propagate Up 2. The update has the RLP Field set to 1 (i.e. 'Do not Propagate Up
or Lateral') indication for one or more hops (excluding the most or Lateral') indication for one or more hops (excluding the most
recent) in the AS path. recent) in the AS path.
The reason for stating "excluding the most recent" in the above The reason for stating "excluding the most recent" in the above
algorithm is as follows. An ISP should look at RLP values set by algorithm is as follows. An ISP should look at RLP values set by
ASes preceding the immediate sending AS in order to ascertain a leak. ASes preceding the immediate sending AS in order to ascertain a leak.
The receiving router already knows that the most recent hop in the The receiving router already knows that the most recent hop in the
update is from its customer or lateral-peer AS to itself, and it does update is from its customer or lateral-peer AS to itself, and it does
not need to rely on the RLP field value set by said AS for detection not need to rely on the RLP field value set by that AS (i.e the
of route leaks. (Note: The utility of RLP value set by the peer immediate neighbor AS in the AS path) for detection of route leaks.
sending the update was discussed above in Section 3.2.)
If the RLP encoding is secured by BGPsec (see Section 3.1) and hence If the RLP encoding is secured by BGPsec (see Section 4.3) and hence
protected against tampering by intermediate ASes, then there would be protected against tampering by intermediate ASes, then there would be
added certainty in the route-leak detection algorithm described above added certainty in the route-leak detection algorithm described above
(see discussions in Section 5.1 and Section 5.2). (see discussions in Section 6.1 and Section 6.2).
3.4. Possible Actions at a Receiving Router for Mitigation 4.5. Possible Actions at a Receiving Router for Mitigation
After applying the above detection algorithm, a receiving router may After applying the above detection algorithm, a receiving router may
use any policy-based algorithm of its own choosing to mitigate any use any policy-based algorithm of its own choosing to mitigate any
detected route leaks. An example receiver algorithm for mitigating a detected route leaks. An example receiver algorithm for mitigating a
route leak is as follows: route leak is as follows:
o If an update from a customer or lateral peer AS is marked as a o If an update from a customer or lateral peer AS is marked as a
'Route Leak', then the receiving router SHOULD prefer an alternate 'Route Leak' (see Section 4.4), then the receiving router SHOULD
unmarked route if available. prefer an alternate unmarked route.
o If no alternate unmarked route is available, then the route marked o If no alternate unmarked route is available, then a route marked
as a 'Route Leak' MAY be accepted. as a 'Route Leak' MAY be accepted.
A basic principle here is that if an AS receives and marks a customer A basic principle here is that if an AS receives and marks a customer
route as 'Route Leak', then the AS should override the "prefer route as 'Route Leak', then the AS should override the "prefer
customer route" policy, and instead prefer an alternate 'clean' route customer route" policy, and instead prefer an alternate 'clean' route
learned from another customer, a lateral peer, or a transit provider. learned from another customer, a lateral peer, or a transit provider.
This can be implemented by adjusting the local preference for the This can be implemented by adjusting the local preference for the
routes in consideration. routes in consideration.
4. Stopgap Solution when Only Origin Validation is Deployed 5. Stopgap Solution when Only Origin Validation is Deployed
A stopgap method is described here for detection and mitigation of A stopgap method is described here for detection and mitigation of
route leaks for the intermediate phase when OV is deployed but BGP route leaks for the intermediate phase when OV is deployed but BGP
protocol on the wire is unchanged. The stopgap solution can be in protocol on the wire is unchanged. The stopgap solution can be in
the form of construction of a prefix filter list from ROAs. A the form of construction of a prefix filter list from ROAs. A
suggested procedure for constructing such a list comprises of the suggested procedure for constructing such a list comprises of the
following steps: following steps:
o ISP makes a list of all the ASes (Cust_AS_List) that are in its o ISP makes a list of all the ASes (Cust_AS_List) that are in its
customer cone (ISP's own AS is also included in the list). (Some customer cone (ISP's own AS is also included in the list). (Some
skipping to change at page 12, line 22 skipping to change at page 13, line 22
Special considerations with regard to the above procedure may be Special considerations with regard to the above procedure may be
needed for DDoS mitigation service providers. They typically needed for DDoS mitigation service providers. They typically
originate or announce a DDoS victim's prefix to their own ISP on a originate or announce a DDoS victim's prefix to their own ISP on a
short notice during a DDoS emergency. Some provisions would need to short notice during a DDoS emergency. Some provisions would need to
be made for such cases, and they can be determined with the help of be made for such cases, and they can be determined with the help of
inputs from DDoS mitigation service providers. inputs from DDoS mitigation service providers.
For developing a list of all the ASes (Cust_AS_List) that are in the For developing a list of all the ASes (Cust_AS_List) that are in the
customer cone of an ISP, the AS path based Outbound Route Filter customer cone of an ISP, the AS path based Outbound Route Filter
(ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see (ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see
discussion in Section 5.4). discussion in Section 6.4).
Another technique based on AS_PATH filters is described in Another technique based on AS_PATH filters is described in
[Snijders]. This method is applicable to very large ISPs (i.e. big [Snijders]. This method is applicable to very large ISPs (i.e. big
networks) that have lateral peering. For a pair of such very large networks) that have lateral peering. For a pair of such very large
ISPs, say A and B, the method depends on ISP A communicating out-of- ISPs, say A and B, the method depends on ISP A communicating out-of-
band (e.g. by email) with ISP B about whether or not it (ISP A) has band (e.g. by email) with ISP B about whether or not it (ISP A) has
any transit providers. This out-of-band knowledge enables ISP B to any transit providers. This out-of-band knowledge enables ISP B to
apply suitable AS_PATH filtering criteria for routes involving the apply suitable AS_PATH filtering criteria for routes involving the
presence of ISP A in the path and prevent certain kinds of route presence of ISP A in the path and prevent certain kinds of route
leaks (see [Snijders] for details). leaks (see [Snijders] for details).
5. Design Rationale and Discussion 6. Design Rationale and Discussion
This section provides design justifications for the methodology This section provides design justifications for the methodology
specified in Section 3, and also answers some questions that are specified in Section 4, and also answers some questions that are
anticipated or have been raised in the IETF IDR and SIDR working anticipated or have been raised in the IETF IDR and SIDR working
group meetings. group meetings.
5.1. Is route-leak solution without cryptographic protection a serious 6.1. Is route-leak solution without cryptographic protection a serious
attack vector? attack vector?
It has been asked if a route-leak solution without BGPsec, i.e. when It has been asked if a route-leak solution without BGPsec, i.e. when
RLP bits are not protected, can turn into a serious new attack RLP Fields are not protected, can turn into a serious new attack
vector. The answer seems to be: not really! Even the NLRI and vector. The answer seems to be: not really! Even the NLRI and
AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPsec seek to AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPsec seek to
fix that. Consider the following. Say, if 99% of route leaks are fix that. Consider the following. Say, if 99% of route leaks are
accidental and 1% are malicious, and if route-leak solution without accidental and 1% are malicious, and if route-leak solution without
BGPsec eliminates the 99%, then perhaps it is worth it (step in the BGPsec eliminates the 99%, then perhaps it is worth it (step in the
right direction). When BGPsec comes into deployment, the route-leak right direction). When BGPsec comes into deployment, the route-leak
protection (RLP) bits can be mapped into BGPsec (using the Flags protection (RLP) bits can be mapped into BGPsec (using the Flags
field) and then necessary security will be in place as well (within field) and then necessary security will be in place as well (within
each BGPsec island as and when they emerge). each BGPsec island as and when they emerge).
Further, let us consider the worst-case damage that can be caused by Further, let us consider the worst-case damage that can be caused by
maliciously manipulating the RLP bits in an implementation without maliciously manipulating the RLP Field values in an implementation
cryptographic protection (i.e. sans BGPsec). Manipulation of the RLP without cryptographic protection (i.e. sans BGPsec). Manipulation of
bits can result in one of two types of attacks: (a) Upgrade attack the RLP bits can result in one of two types of attacks: (a) Upgrade
and (b) Downgrade attack. Descriptions and discussions about these attack and (b) Downgrade attack. Descriptions and discussions about
attacks follow. In what follows, P2C stands for transit provider to these attacks follow. In what follows, P2C stands for transit
customer (Down); C2P stands for customer to transit provider (Up), provider to customer (Down); C2P stands for customer to transit
and p2p stands for peer to peer (lateral or non-transit provider (Up), and p2p stands for peer to peer (lateral or non-
relationship). transit relationship).
(a) Upgrade attack: An AS that wants to intentionally leak a route (a) Upgrade attack: An AS that wants to intentionally leak a route
would alter the RLP encodings for the preceding hops from 1 (i.e. would alter the RLP encodings for the preceding hops from 1 (i.e.
'Do not Propagate Up or Lateral') to 0 (default) wherever applicable. 'Do not Propagate Up or Lateral') to 0 (default) wherever applicable.
This poses no problem for a route that keeps propagating in the This poses no problem for a route that keeps propagating in the
'Down' (P2C) direction. However, for a route that propagates 'Up' 'Down' (P2C) direction. However, for a route that propagates 'Up'
(C2P) or 'Lateral' (p2p), the worst that can happen is that a route (C2P) or 'Lateral' (p2p), the worst that can happen is that a route
leak goes undetected. That is, a receiving router would not be able leak goes undetected. That is, a receiving router would not be able
to detect the leak for the route in question by the RLP mechanism to detect the leak for the route in question by the RLP mechanism
described here. However, the receiving router may still detect and described here. However, the receiving router may still detect and
skipping to change at page 14, line 5 skipping to change at page 15, line 5
customer prefixes. So an AS or ISP is not likely to change an RLP customer prefixes. So an AS or ISP is not likely to change an RLP
value 0 to 1 intentionally. If a route leak is detected (due to value 0 to 1 intentionally. If a route leak is detected (due to
intentional or accidental downgrade) by a receiving router, it would intentional or accidental downgrade) by a receiving router, it would
prefer an alternate 'clean' route from a transit provider or peer prefer an alternate 'clean' route from a transit provider or peer
over a 'marked' route from a customer. It may end up with a over a 'marked' route from a customer. It may end up with a
suboptimal path. In order to have reachability, the receiving router suboptimal path. In order to have reachability, the receiving router
would accept a 'marked' route if there is no alternative that is would accept a 'marked' route if there is no alternative that is
'clean'. So RLP downgrade attacks (intentional or accidental) would 'clean'. So RLP downgrade attacks (intentional or accidental) would
be quite rare, and the consequences do not appear to be grave. be quite rare, and the consequences do not appear to be grave.
5.2. Combining results of route-leak detection, OV and BGPsec 6.2. Combining results of route-leak detection, OV and BGPsec
validation for path selection decision validation for path selection decision
Combining the results of route-leak detection, OV, and BGPsec Combining the results of route-leak detection, OV, and BGPsec
validation for path selection decision is up to local policy in a validation for path selection decision is up to local policy in a
receiving router. As an example, a router may always give precedence receiving router. As an example, a router may always give precedence
to outcomes of OV and BGPsec validation over that of route-leak to outcomes of OV and BGPsec validation over that of route-leak
detection. That is, if an update fails OV or BGPsec validation, then detection. That is, if an update fails OV or BGPsec validation, then
the update is not considered a candidate for path selection. the update is not considered a candidate for path selection.
Instead, an alternate update is chosen that passed OV and BGPsec Instead, an alternate update is chosen that passed OV and BGPsec
validation and additionally was not marked as route leak. validation and additionally was not marked as route leak.
If only OV is deployed (and not BGPsec), then there are six possible If only OV is deployed (and not BGPsec), then there are six possible
combinations between OV and route-leak detection outcomes. Because combinations between OV and route-leak detection outcomes. Because
there are three possible outcomes for OV (NotFound, Valid, and there are three possible outcomes for OV (NotFound, Valid, and
Invalid) and two possible outcomes for route-leak detection (marked Invalid) and two possible outcomes for route-leak detection (marked
as leak and not marked). If OV and BGPsec are both deployed, then as leak and not marked). If OV and BGPsec are both deployed, then
there are twelve possible combinations between OV, BGPsec validation, there are twelve possible combinations between OV, BGPsec validation,
and route-leak detection outcomes. As stated earlier, since BGPsec and route-leak detection outcomes. As stated earlier, since BGPsec
protects the RLP encoding, there would be added certainty in route- protects the RLP encoding, there would be added certainty in route-
leak detection outcome if an update is BGPsec valid (see leak detection outcome if an update is BGPsec valid (see
Section 5.1). Section 6.1).
5.3. Are there cases when valley-free violations can be considered 6.3. Are there cases when valley-free violations can be considered
legitimate? legitimate?
There are studies in the literature [Anwar] [Giotsas] [Wijchers] There are studies in the literature [Anwar] [Giotsas] [Wijchers]
observing and analyzing the behavior of routes announced in BGP observing and analyzing the behavior of routes announced in BGP
updates using data gathered from the Internet. In particular, the updates using data gathered from the Internet. In particular, the
studies have focused on how often there appear to be valley-free studies have focused on how often there appear to be valley-free
(e.g. Gao-Rexford [Gao] model) violations, and if they can be (e.g. Gao-Rexford [Gao] model) violations, and if they can be
explained [Anwar]. One important consideration for explanation of explained [Anwar]. One important consideration for explanation of
violations is per-prefix routing policies, i.e. routes for prefixes violations is per-prefix routing policies, i.e. routes for prefixes
with different business models are often sent over the same link. with different peering relationships may be sent over the same link.
One encouraging result reported in [Anwar] is that when per-prefix One encouraging result reported in [Anwar] is that when per-prefix
routing policies are taken into consideration in the data analysis, routing policies are taken into consideration in the data analysis,
more than 80% of the observed routing decisions fit the valley-free more than 80% of the observed routing decisions fit the valley-free
model (see Section 4.3 and SPA-1 data in Figure 2). [Anwar] also model (see Section 4.3 and SPA-1 data in Figure 2). [Anwar] also
observes, "it is well known that this model [the basic Gao-Rexford observes, "it is well known that this model [the basic Gao-Rexford
model and some variations of it] fails to capture many aspects of the model and some variations of it] fails to capture many aspects of the
interdomain routing system. These aspects include AS relationships interdomain routing system. These aspects include AS relationships
that vary based on the geographic region or destination prefix, and that vary based on the geographic region or destination prefix, and
traffic engineering via hot-potato routing or load balancing." So traffic engineering via hot-potato routing or load balancing." So
there may be potential for explaining the remaining (20% or less) there may be potential for explaining the remaining (20% or less)
violations of valley-free as well. violations of valley-free as well.
One major design factor in the methodology described in this document One major design factor in the methodology described in this document
is that the Route-Leak Protection (RLP) encoding is per prefix. So is that the Route-Leak Protection (RLP) encoding is per prefix. So
the proposed solution is consistent with ISPs' per-prefix routing the proposed solution is consistent with ISPs' per-prefix routing
policies. Large global and other major ISPs will be the likely early policies. Large global and other major ISPs will be the likely early
adopters, and they are expected to have expertise in configuring adopters, and they are expected to have expertise in setting policies
policies (including per prefix policies, if applicable), and make (including per prefix policies, if applicable), and make proper use
proper use of the RLP indications on a per prefix basis. When said of the RLP indications on a per prefix basis. When the large ISPs
large ISPs participate in this solution deployment, it is envisioned participate in this solution deployment, it is envisioned that they
that they would form a ring of protection against route leaks, and would form a ring of protection against route leaks, and co-
co-operatively avoid many of the common types of route leaks that are operatively avoid many of the common types of route leaks that are
observed. Route leaks may still happen occasionally within the observed. Route leaks may still happen occasionally within the
customer cones (if some customer ASes are not participating or not customer cones (if some customer ASes are not participating or not
diligently implementing RLP), but said leaks would be much less diligently implementing RLP), but said leaks would be much less
likely to propagate from one large participating ISP to another. likely to propagate from one large participating ISP to another.
5.4. Comparison with other methods, routing security BCP 6.4. Comparison with other methods (routing security BCPs)
It is reasonable to ask if techniques considered in BCPs such It is reasonable to ask if techniques considered in BCPs such
as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be
adequate to address route leaks. The prefix filtering adequate to address route leaks. The prefix filtering
recommendations in the BCPs may be complementary but not adequate. recommendations in the BCPs may be complementary but not adequate.
The difficulty is in ISPs' ability to construct prefix filters that The difficulty is in ISPs' ability to construct prefix filters that
represent their customer cones (CC) accurately, especially when there represent their customer cones (CC) accurately, especially when there
are many levels in the hierarchy within the CC. In the RLP-encoding are many levels in the hierarchy within the CC. In the RLP-encoding
based solution described here, AS operators signal for each route based solution described here, AS operators signal for each route
propagated, if it SHOULD NOT be subsequently propagated to a transit propagated, if it SHOULD NOT be subsequently propagated to a transit
provider or peer. provider or peer.
AS path based Outbound Route Filter (ORF) described in AS path based Outbound Route Filter (ORF) described in
[draft-ietf-idr-aspath-orf] is also an interesting complementary [draft-ietf-idr-aspath-orf] is also an interesting complementary
technique. It can be used as an automated collaborative messaging technique. It can be used as an automated collaborative messaging
system (implemented in BGP) for ISPs to try to develop a complete system (implemented in BGP) for ISPs to try to develop a complete
view of the ASes and AS paths in their CCs. Once an ISP has that view of the ASes and AS paths in their CCs. Once an ISP has that
view, then AS path filters can be possibly used to detect route view, then AS path filters can be possibly used to detect route
leaks. One limitation of this technique is that it cannot duly take leaks. One limitation of this technique is that it cannot duly take
into account the fact that routes for prefixes with different into account the fact that routes for prefixes with different peering
business models are often sent over the same link between ASes. relationships may be sent over the same link between ASes. Also, the
Also, the success of AS path based ORF depends on whether ASes at all success of AS path based ORF depends on whether ASes at all levels of
levels of the hierarchy in a CC participate and provide accurate the hierarchy in a CC participate and provide accurate information
information (in the ORF messages) about the AS paths they expect to (in the ORF messages) about the AS paths they expect to have in their
have in their BGP updates. BGP updates.
5.5. Per-Hop RLP Flags or Single RLP Flag per Update? 6.5. Per-Hop RLP Field or Single RLP Flag per Update?
The route-leak detection and mitigation mechanism described in this The route-leak detection and mitigation mechanism described in this
document is based on setting RLP flags on a per-hop basis. There is document is based on setting RLP Fields on a per-hop basis. There is
another possible mechanism based on a single RLP flag per update. another possible mechanism based on a single RLP flag per update.
Method A - Per-Hop RLP Flags: The sender on each hop in the AS path Method A - Per-Hop RLP Field: The sender (eBGP router) on each hop in
sets RLP = 1 if sending the update to a customer or lateral peer the AS path sets its RLP Field = 1 if sending the update to a
(regardless of what the previous ASes in the path set their bits to). customer or lateral peer (see Section 4.3) and Section 4.3.1). No AS
No AS (if operating correctly) would rewrite/reset the RLP flags set (if operating correctly) would rewrite the RLP Field set by any
by any preceding AS (see Section 3.1). preceding AS.
Method B - Single RLP Flag per Update: As it propagates, the update Method B - Single RLP Flag per Update: As it propagates, the update
always has only one RLP flag. Once an AS (in the update path) would have at most one RLP flag. Once an eBGP router (in the update
determines that it is sending an update towards a customer or lateral path) determines that it is sending an update towards a customer or
peer AS, it sets the RLP flag. Once the flag is set, it would be lateral peer AS, it sets the RLP flag. The flag value equals the AS
required that subsequent ASes in the path should always leave the number of the eBGP router that is setting it. Once the flag is set,
flag set. subsequent ASes in the path must propagate the flag as is.
Method B is functionally deficient when compared to Method A for To compare Methods A and B, consider the example illustrated in
detection of route leaks. This becomes quite evident from the Figure 3. Consider a partial deployment scenario in which AS1, AS2,
illustration in Figure 3. With Method B in use, it is evident that AS3 and AS5 participate in RLP, and AS4 does not. AS1 (2 levels deep
when AS3 receives an update, {p [AS2, AS1] RLP =1] from AS2, there is in AS3's customer cone) has imperfect RLP operation. Each complying
no way for it (AS3) to distinguish and tell if AS2 is leaking a route AS's route leak mitigation policy is to prefer an update not marked
learned from a transit-provider or lateral peer (AS1), or as route leak (see Section 4.5). If there is no alternative, then a
legitimately forwarding a route learned from a customer (AS1). transit-provider may propagate a marked update from a customer. In
Method A does not suffer from this inadequacy because if Method A this example, multi-homed AS4 leaks a route received for prefix Q
were used, then AS3 in Figure 3 will have the benefit of seeing the from transit-provider AS3 to transit-provider AS5.
RLP field values set by AS1 and AS2 individually. Thus in Method A,
a legitimate customer route forwarded from AS2 to AS3 will be
distinguishable from a leaked transit-provider or lateral-peer route.
+-----+ +-----+ peer to peer (p2p) relation +-----+ +-----------+ RLP=1 +-----------+
p--| AS1 |-------->| AS2 |----------------------------->| AS3 | | AS3 |---------->| AS5 |
+-----+ +-----+ Update --> +-----+ |(Major ISP)| U2 |(Major ISP)|
Method B: {p [AS2 AS1] RLP=1} +-----------+ +-----------+
(independent of AS1's relationship with AS2) /\ \ /\ U1
** Method B fails to differentiate leak versus legitimate Route for Q propagated / \RLP=1 /
due to lack of /RLP=0 \ / (route leak;
alternate route / \/ / bad behavior)
+---------+ +-------------+
| AS2 | | AS4 |
+---------+ +-------------+
/\ (legacy; does not support RLP)
/
/
/RLP=1 (set incorrectly)
/
+----------+
| AS1 |
+----------+
/\
/
/ Prefix Q
Method A: {p [AS2 AS1] {RLP2=1 RLP1=1}} -- route leak Figure 3: Example for comparison of Method A vs. Method B
(if AS1 is transit-provider or lateral peer of AS2)
Method A: {p [AS2 AS1] {RLP2=1 RLP1=0}} -- legitimate
(if AS1 is a customer of AS2)
** Method A successfully differentiates leak versus legitimate
Figure 3: Illustration of the basic notion of a route leak. If Method A is implemented in the network, the two BGP updates for
prefix Q received at AS5 are (note that AS4 is not participating in
RLP):
In general, Method A is more robust than Method B in the presence of U1A: Q [AS4 AS3 AS2 AS1] {RLP3(AS3)=1, RLP2(AS2)=0, RLP1(AS1)=1}
faulty operation (including route leaks) or lack of upgrade (to ..... from AS4
perform RLP) on part of an AS in the AS path. [Sriram] further
illustrates this (see slides 5-9) under multiple partial deployment /
faulty implementation scenarios.
Further, it is feasible to provide cryptographic protection for the U2A: Q [AS3 AS2 AS1] {RLP3(AS3)=1, RLP2(AS2)=0, RLP1(AS1)=1} .....
RLP encoding in the case Method A with the help of the BGPsec from AS3
protocol (see Section 3.1.2). Method B is not amenable to be mapped
into BGPsec.
6. Security Considerations Alternatively, if Method B is implemented in the network, the two BGP
updates for prefix Q received at AS5 are:
U1B: Q [AS4 AS3 AS2 AS1] {RLP(AS1)=1} ..... from AS4
U2B: Q [AS3 AS2 AS1] {RLP(AS1)=1} ..... from AS3
All received routes for prefix Q at AS5 are marked as route leak in
either case (Method A or B). In the case of Method A, AS5 can use
additional information gleaned from the RLP fields in the updates to
possibly make a better best path selection. For example, AS5 can
determine that U1A update received from its customer AS4 exhibits
violation of two RLP fields (those set by AS1 and AS3) and one of
them was set just two hops away. But U2A update exhibits that only
one RLP field was violated and that was set three hops back. Based
on this logic, AS5 may prefer U2A over U1A (even though U1A is a
customer route). This would be a good decision. However, Method B
does not facilitate this kind of more rational decision process.
With Method B, both updates U1B and U2B exhibit that they violated
only one RLP field (set by AS1 several hops away). AS5 may then
prefer U1B over U2B since U1B is from a customer, and that would be
bad decision. This illustrates that, due to more information in per-
hop RLP Fields, Method A seems to be operationally more beneficial
than Method B.
Further, for detection and notification of neighbor AS's non-
compliance, Method A (per-hop RLP) is better than Method B (single
RLP). With Method A, the bad behavior of AS4 would be explicitly
evident to AS5 since it violated AS3's (only two hops away) RLP field
as well. AS5 would alert AS4 and also AS2 would alert AS1 about lack
of compliance (when Method A is used). With Method B, the alerting
process may not be as expeditious.
7. Security Considerations
The proposed Route-Leak Protection (RLP) field requires cryptographic The proposed Route-Leak Protection (RLP) field requires cryptographic
protection in order to prevent malicious route leaks. Since it is protection in order to prevent malicious route leaks. Since it is
proposed that the RLP field be included in the Flags field in the proposed that the RLP field be included in the Flags field in the
Secure_Path Segment in BGPsec updates, the cryptographic security Secure_Path Segment in BGPsec updates, the cryptographic security
mechanisms in BGPsec are expected to also apply to the RLP field. mechanisms in BGPsec are expected to also apply to the RLP field.
The reader is therefore directed to the security considerations The reader is therefore directed to the security considerations
provided in [I-D.ietf-sidr-bgpsec-protocol]. provided in [I-D.ietf-sidr-bgpsec-protocol].
7. IANA Considerations 8. IANA Considerations
A request will be made to IANA for assignment of an attribute type IANA is requested to register a new optional, non-transitive BGP Path
code for the proposed new BGP RLP attribute. Attribute, named "Preventive Route Leak Protection (pRLP)" in the BGP
Path Attributes registry. The attribute type code is TBD. The
reference for this new attribute is this document (i.e. the RFC that
replaces this draft). The length of this new attribute is 0.
8. Acknowledgements IANA is requested to register a new optional, transitive BGP Path
Attribute, named "Route Leak Protection" in the BGP Path Attributes
registry. The attribute type code is TBD. The reference for this
new attribute is this document (i.e. the RFC that replaces this
draft). The length field of this attribute is 2 octets, and the
length of the value field of this attribute is variable (see
Figure 2) in Section 4.3.1 of this document).
The authors wish to thank Danny McPherson and Eric Osterweil for 9. Acknowledgements
discussions related to this work. Also, thanks are due to Jared
Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff
Huston, Randy Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes
George, Chris Morrow, and Sandy Murphy for comments, suggestions, and
critique. The authors are also thankful to Padma Krishnaswamy,
Oliver Borchert, and Okhee Kim for their comments and review.
9. References The authors wish to thank Jared Mauch, Jeff Haas, Job Snijders,
Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy
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
also thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim
for their review and comments.
9.1. Normative References 10. References
10.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,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
9.2. Informative References 10.2. Informative References
[Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,
and N. Katz-Bassett, "Investigating Interdomain Routing and N. Katz-Bassett, "Investigating Interdomain Routing
Policies in the Wild", ACM Internet Measurement Policies in the Wild", ACM Internet Measurement
Conference (IMC), October 2015, Conference (IMC), October 2015,
<http://www.cs.usc.edu/assets/007/94928.pdf>. <http://www.cs.usc.edu/assets/007/94928.pdf>.
[Cowie2010] [Cowie2010]
Cowie, J., "China's 18 Minute Mystery", Dyn Cowie, J., "China's 18 Minute Mystery", Dyn
Research/Renesys Blog, November 2010, Research/Renesys Blog, November 2010,
skipping to change at page 19, line 19 skipping to change at page 21, line 19
CTelecom.html>. CTelecom.html>.
[Huston2012] [Huston2012]
Huston, G., "Leaking Routes", March 2012, Huston, G., "Leaking Routes", March 2012,
<http://labs.apnic.net/blabs/?p=139/>. <http://labs.apnic.net/blabs/?p=139/>.
[Huston2014] [Huston2014]
Huston, G., "What's so special about 512?", September Huston, G., "What's so special about 512?", September
2014, <http://labs.apnic.net/blabs/?p=520/>. 2014, <http://labs.apnic.net/blabs/?p=520/>.
[I-D.ietf-grow-route-leak-problem-definition]
Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", draft-ietf-grow-route-leak-problem-
definition-06 (work in progress), May 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-21 (work Specification", draft-ietf-sidr-bgpsec-protocol-22 (work
in progress), December 2016. in progress), January 2017.
[I-D.ymbk-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Detection and Filtering using Roles in
Update and Open messages", draft-ymbk-idr-bgp-open-
policy-02 (work in progress), November 2016.
[Kapela-Pilosov] [Kapela-Pilosov]
Pilosov, A. and T. Kapela, "Stealing the Internet: An Pilosov, A. and T. Kapela, "Stealing the Internet: An
Internet-Scale Man in the Middle Attack", DEFCON-16 Las Internet-Scale Man in the Middle Attack", DEFCON-16 Las
Vegas, NV, USA, August 2008, Vegas, NV, USA, August 2008,
<https://www.defcon.org/images/defcon-16/dc16- <https://www.defcon.org/images/defcon-16/dc16-
presentations/defcon-16-pilosov-kapela.pdf>. presentations/defcon-16-pilosov-kapela.pdf>.
[Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage", [Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage",
ThousandEyes Blog, June 2015, ThousandEyes Blog, June 2015,
skipping to change at page 21, line 19 skipping to change at page 23, line 19
[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,
<http://www.rfc-editor.org/info/rfc6811>. <http://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, <http://www.rfc-editor.org/info/rfc7454>. February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[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, <http://www.rfc-editor.org/info/rfc7908>.
[Snijders] [Snijders]
Snijders, J., "Practical everyday BGP filtering with Snijders, J., "Practical everyday BGP filtering with
AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA, AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA,
June 2016, <https://www.nanog.org/sites/default/files/ June 2016, <https://www.nanog.org/sites/default/files/
Snijders_Everyday_Practical_Bgp.pdf>. Snijders_Everyday_Practical_Bgp.pdf>.
[Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. [Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.
Robachevsky , "Methods for Detection and Mitigation of BGP Robachevsky , "Methods for Detection and Mitigation of BGP
Route Leaks", IETF-95 IDR WG Meeting), April 2016, Route Leaks", IETF-95 IDR WG Meeting), April 2016,
<https://www.ietf.org/proceedings/95/slides/slides-95-idr- <https://www.ietf.org/proceedings/95/slides/slides-95-idr-
 End of changes. 72 change blocks. 
317 lines changed or deleted 442 lines changed or added

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