draft-ietf-idr-route-leak-detection-mitigation-02.txt   draft-ietf-idr-route-leak-detection-mitigation-03.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: September 15, 2016 B. Dickson Expires: November 24, 2016 B. Dickson
K. Patel K. Patel
Cisco Cisco
A. Robachevsky A. Robachevsky
Internet Society Internet Society
March 14, 2016 May 23, 2016
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-02 draft-ietf-idr-route-leak-detection-mitigation-03
Abstract Abstract
In [I-D.ietf-grow-route-leak-problem-definition], the authors have [I-D.ietf-grow-route-leak-problem-definition] provides a definition
provided a definition of the route leak problem, and also enumerated of the route leak problem, and also enumerates several types of route
several types of route leaks. In this document, we first examine leaks. This document first examines which of those route-leak types
which of those route-leak types are detected and mitigated by the are detected and mitigated by the existing origin validation (OV)
existing origin validation (OV) [RFC 6811]. It is recognized that OV [RFC 6811]. It is recognized that OV offers a limited detection and
offers a limited detection and mitigation capability against route mitigation capability against route leaks. This document specifies
leaks. This document proposes an enhancement that significantly enhancements that significantly extend the route-leak prevention,
extends the route-leak detection and mitigation capabilities of BGP. detection, and mitigation capabilities of BGP. One solution
The solution involves carrying a per-hop route-leak protection (RLP) component involves carrying a per-hop route-leak protection (RLP)
field in BGP updates. The RLP field is proposed be carried in an field in BGP updates. The RLP field is proposed be carried in a new
optional transitive path attribute. The solution is meant to be optional transitive attribute, called BGP RLP attribute. The
initially implemented as an enhancement of BGP without requiring solution is meant to be initially implemented as an enhancement of
BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol].
deployed in the future, the solution can be incorporated in BGPsec, However, when BGPsec is deployed in the future, the solution can be
enabling cryptographic protection for the RLP field. That would be incorporated in BGPsec, enabling cryptographic protection for the RLP
one way of implementing the proposed solution in a secure way. It is field. That would be one way of implementing the proposed solution
not claimed that the solution detects all possible types of route in a secure way. The document also includes a stopgap method for
leaks but it detects several types, especially considering some detection and mitigation of route leaks for an intermediate phase
significant route-leak occurrences that have been observed in recent when OV is deployed but BGP protocol on the wire is unchanged.
years. 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 15, 2016. This Internet-Draft will expire on November 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4 3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4
3.1. Route-Leak Protection (RLP) Field Encoding by Sending 3.1. Route-Leak Protection (RLP) Field Encoding by Sending
Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 Router . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Recommended Actions at a Receiving Router for Detection 3.1.1. BGP RLP Attribute . . . . . . . . . . . . . . . . . . 8
of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Carrying RLP Flag Values in the BGPsec Flags . . . . 9
3.3. Possible Actions at a Receiving Router for Mitigation . . 9 3.2. Intra-AS Messaging for Route Leak Prevention . . . . . . 9
4. Stopgap Solution when Only Origin Validation is Deployed . . 9 3.3. Recommended Actions at a Receiving Router for Detection
5. Design Rationale and Discussion . . . . . . . . . . . . . . . 10 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 10
3.4. Possible Actions at a Receiving Router for Mitigation . . 11
4. Stopgap Solution when Only Origin Validation is Deployed . . 11
5. Design Rationale and Discussion . . . . . . . . . . . . . . . 12
5.1. Is route-leak solution without cryptographic protection a 5.1. Is route-leak solution without cryptographic protection a
serious attack vector? . . . . . . . . . . . . . . . . . 10 serious attack vector? . . . . . . . . . . . . . . . . . 12
5.2. Combining results of route-leak detection, OV and BGPsec 5.2. Combining results of route-leak detection, OV and BGPsec
validation for path selection decision . . . . . . . . . 12 validation for path selection decision . . . . . . . . . 13
5.3. Are there cases when valley-free violations can be 5.3. Are there cases when valley-free violations can be
considered legitimate? . . . . . . . . . . . . . . . . . 12 considered legitimate? . . . . . . . . . . . . . . . . . 14
5.4. Comparison with other methods, routing security BCP . . . 13 5.4. Comparison with other methods, routing security BCP . . . 15
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Per-Hop RLP Flags or Single RLP Flag per Update? . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
In [I-D.ietf-grow-route-leak-problem-definition], the authors have [I-D.ietf-grow-route-leak-problem-definition] provides a definition
provided a definition of the route leak problem, and also enumerated of the route leak problem, and also enumerates several types of route
several types of route leaks. In this document, we first examine leaks. This document first examines which of those route-leak types
which of those route-leak types are detected and mitigated by the are detected and mitigated by the existing Origin Validation (OV)
existing Origin Validation (OV) [RFC6811] method. OV and BGPsec path [RFC6811] method. OV and BGPsec path validation
validation [I-D.ietf-sidr-bgpsec-protocol] together offer mechanisms [I-D.ietf-sidr-bgpsec-protocol] together offer mechanisms to protect
to protect against re-originations and hijacks of IP prefixes as well against re-originations and hijacks of IP prefixes as well as man-in-
as man-in-the-middle (MITM) AS path modifications. Route leaks (see the-middle (MITM) AS path modifications. Route leaks (see
[I-D.ietf-grow-route-leak-problem-definition] and references cited at [I-D.ietf-grow-route-leak-problem-definition] and references cited at
the back) are another type of vulnerability in the global BGP routing the back) are another type of vulnerability in the global BGP routing
system against which OV offers only partial protection. BGPsec (i.e. system against which OV offers only partial protection. BGPsec (i.e.
path validation) provides cryptographic protection for some aspects path validation) provides cryptographic protection for some aspects
of BGP update messages, but in its current form BGPsec doesn't offer of BGP update messages, but in its current form BGPsec doesn't offer
any 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
[I-D.ietf-grow-route-leak-problem-definition], where the current OV [I-D.ietf-grow-route-leak-problem-definition], where the OV method
method does't offer a solution, this document proposes an enhancement does't offer a solution, this document specifies enhancements that
that would significantly extend the detection and mitigation significantly extend the route-leak prevention, detection, and
capabilities of BGP. The solution involves carrying a per-hop route- mitigation capabilities of BGP. One solution component involves
leak protection (RLP) field in BGP updates. The RLP field is carrying a per-hop route-leak protection (RLP) field in BGP updates.
proposed be carried in an optional transitive path attribute. The The RLP field is proposed be carried in a new optional transitive
solution is meant to be initially implemented as an enhancement of attribute, called BGP RLP attribute. The solution is meant to be
BGP without requiring BGPsec. However, when BGPsec is deployed in initially implemented as an enhancement of BGP without requiring
the future, the solution can be incorporated in BGPsec, enabling BGPsec. However, when BGPsec is deployed in the future, the solution
cryptographic protection for the RLP field. That would be one way of can be incorporated in BGPsec, enabling cryptographic protection for
implementing the proposed solution in a secure way. It is not the RLP field. That would be one way of implementing the proposed
claimed that the solution detects all possible types of route leaks solution in a secure way. It is not claimed that the solution
but it detects several types, especially considering some significant detects all possible types of route leaks but it detects several
route-leak occurrences that have been observed in recent years. The types, especially considering some significant route-leak occurrences
document also includes a stopgap method (in Section 4) for detection that have been observed in recent years. The document also includes
and mitigation of route leaks for an intermediate phase when OV is a stopgap method (in Section 4) for detection and mitigation of route
deployed but BGP protocol on the wire is unchanged. 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 The basic idea and mechanism embodied in the proposed solution is
based on setting an attribute in BGP route announcement to manage the based on setting an attribute in BGP route announcement to manage the
transmission/receipt of the announcement based on the type of transmission/receipt of the announcement based on the type of
neighbor (e.g. customer, transit provider, etc.). Documented prior neighbor (e.g. customer, transit provider, etc.). Documented prior
work related to said basic idea and mechanism dates back to at least work related to said basic idea and mechanism dates back to at least
the 1980's. Some examples of prior work are: (1) Information flow the 1980's. Some examples of prior work are: (1) Information flow
rules described in [proceedings-sixth-ietf] (see pp. 195-196); (2) rules described in [proceedings-sixth-ietf] (see pp. 195-196); (2)
Link Type described in [RFC1105-obsolete] (see pp. 4-5); (3) Link Type described in [RFC1105-obsolete] (see pp. 4-5); (3)
Hierarchical Recording described in Hierarchical Recording described in
[draft-kunzinger-idrp-ISO10747-01] (see Section 6.3.1.12). The [draft-kunzinger-idrp-ISO10747-01] (see Section 6.3.1.12). The
problem of route leaks and possible solution mechanisms based on problem of route leaks and possible solution mechanisms based on
encoding peering-link type information, e.g. P2C (i.e. Transit- encoding peering-link type information, e.g. P2C (i.e. Transit-
Provider to Customer), C2P (i.e. Customer to Transit-Provider), p2p Provider to Customer), C2P (i.e. Customer to Transit-Provider), p2p
(i.e. peer to peer) etc., in BGPsec updates and protecting the same (i.e. peer to peer) etc., in BGPsec updates and protecting the same
under BGPsec path signatures have been discussed in IETF SIDR WG at under BGPsec path signatures have been discussed in IETF SIDR WG at
least since 2011. Dickson developed the initial Internet draft of least since 2011. [draft-dickson-sidr-route-leak-solns] attempted to
these mechanisms in a BGPsec context; see describe these mechanisms in a BGPsec context. The draft expired in
[draft-dickson-sidr-route-leak-solns]. 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 draft the relationship is relationship is encoded per prefix, as routes for prefixes with
encoded per prefix, as routes for prefixes with different business different business models are often sent over the same link. Also
models are often 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 draft when BGPsec-based block in BGPsec. By contrast, in the current document when BGPsec-
solution is considered, cryptographic protection is provided for based solution is considered, cryptographic protection is provided
Route-Leak Protection (RLP) encoding using the same signature block for Route-Leak Protection (RLP) encoding using the same signature
as that for path signatures (see Section 3.1). block as that for path signatures (see Section 3.1).
3. Mechanisms for Detection and Mitigation of Route Leaks 3. Mechanisms for Detection and Mitigation of Route Leaks
Referring to the enumeration of route leaks discussed in Referring to the enumeration of route leaks discussed in
[I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the [I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the
route-leak detection capability offered by OV and BGPsec for route-leak detection capability offered by OV and BGPsec for
different types of route leaks. (Note: Prefix filtering is not different types of route leaks. (Note: Prefix filtering is not
considered here in this table. Please see Section 4.) considered here in this table. Please see Section 4.)
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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
neither misrouted not denied service. Also, leaked announcements of neither misrouted not denied service. Also, leaked announcements of
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 in our proposed solution method, we need Table 1, it is evident that the solution method should focus
to focus primarily on route leaks of Types 1, 2, 3, and 4. In primarily on route leaks of Types 1, 2, 3, and 4. Section 3.1 and
Section 3.1 and Section 3.2, we describe a simple addition to BGP Section 3.3 describe a simple addition to BGP that facilitates
that facilitates detection of route leaks of Types 1, 2, 3, and 4. detection of route leaks of Types 1, 2, 3, and 4. The simple
The simple addition involves a Route-Leak Protection (RLP) field, addition involves a per-hop Route-Leak Protection (RLP) field. The
which is carried in an optional transitive path attribute in BGP. RLP fields are carried in an optional transitive attribute in BGP,
When BGPsec is deployed, the RLP field will be accommodated in the called BGP RLP attribute. When BGPsec is deployed, the RLP field
existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is will be accommodated in the existing Flags field (see
cryptographically protected under path signatures. [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 3.1. Route-Leak Protection (RLP) Field Encoding by Sending Router
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,
skipping to change at page 7, line 28 skipping to change at page 7, line 28
+---------------+ +---------------+
| 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.
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 00: This is the default value (i.e. "nothing specified"), o 0: This is the default value (i.e. "nothing specified"),
o 01: This is the 'Do not Propagate Up or Lateral' indication; o 1: This is the 'Do not Propagate Up or Lateral' indication; sender
sender indicating that the route SHOULD NOT be forwarded 'Up' indicating that the route SHOULD NOT be forwarded 'Up' towards a
towards a transit-provider AS or to a lateral (i.e. non-transit) transit-provider AS or to a lateral (i.e. non-transit) peer AS.
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 and per neighbor AS
basis. This is because updates for prefixes with different business basis. This is because updates for prefixes with different business
models are often sent over the same link between ASes. models are often sent over the same link between ASes.
There are two different scenarios when a sending AS SHOULD set the There are two different scenarios when a sending AS SHOULD set value
'01' indication in an update: (1) when sending the update to a 1 in the RLP field: (a) when sending the update to a customer AS, and
customer AS, and (2) when sending the update to a lateral peer (i.e. (b) when sending the update to a lateral peer (i.e. non-transit) AS.
non-transit) AS. In essence, in both scenarios, the intent of '01' In essence, in both scenarios, the intent of RLP = 1 is that the
indication is that the neighbor AS and any receiving AS along the neighbor AS and any receiving AS along the subsequent AS path SHOULD
subsequent AS path SHOULD NOT forward the update 'Up' towards its NOT forward the update 'Up' towards its (receiving AS's) transit-
(receiving AS's) transit-provider AS or laterally towards its peer provider AS or laterally towards its peer (i.e. non-transit) AS.
(i.e. non-transit) AS. When sending an update 'Up' to a transit- When sending an update 'Up' to a transit-provider AS, the RLP
provider AS, the RLP encoding should be set to the default value of encoding SHOULD be set to the default value of 0. When a sending AS
'00'. When a sending AS sets the RLP encoding to '00', it is sets the RLP encoding to 0, it is indicating to the receiving AS that
indicating to the receiving AS that the update can be propagated in the update can be propagated in any direction (i.e. towards transit-
any direction (i.e. towards transit-provider, customer, or lateral provider, customer, or lateral peer). This two-state specification
peer). This two-state specification in the RLP field can be shown to in the RLP field works for detection and mitigation of route leaks of
work for detection and mitigation of route leaks of Types 1, 2, 3, Types 1, 2, 3, and 4 which are the focus here (see Section 3.3 and
and 4 which are the focus here (see Section 3.2 and Section 3.3). Section 3.4).
The '10' and '11' values in the RLP field (assuming that two bits are
used to encode it) are currently unassigned, and reserved for An AS SHOULD NOT rewrite/reset the values set by any preceding ASes
possible future use. 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 an optional transitive path attribute. In BGPsec enabled updates in a new BGP optional transitive attribute (see
routers, the RLP encoding SHOULD be accommodated in the existing Section 3.1.1). And it SHOULD be carried in BGPsec in the Flags
Flags field in BGPsec updates. The Flags field is part of the field (see Section 3.1.2).
Secure_Path Segment in BGPsec updates
3.1.1. BGP RLP 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
IANA. The value field of the RLP attribute is defined as a set of
one or more RLP TLVs (Type, Length, Value) as described below:
+-----------------------+ -\
| ASN: N | |
+-----------------------+ > (Most recently added)
| RLP: N | |
+-----------------------+ -/
...........
+-----------------------+ -\
| ASN: 1 | |
+-----------------------+ > (Least recently added)
| RLP: 1 | |
+-----------------------+ -/
Figure 2: RLP TLV format.
RLP TLV has these two components:
ASN: Four octets encoding the public registered AS number of a BGP
speaker.
RLP Flag: One octet encoding the RLP Flag bits. Usage of these flag
bits was described above and will be further discussed in subsequent
sections.
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-
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
be missing in the RLP TLV relative to the AS_PATH.
3.1.2. Carrying RLP Flag Values in the BGPsec Flags
In BGPsec enabled routers, the RLP encoding SHOULD be accommodated in
the existing Flags field in BGPsec updates. The Flags field is part
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. Two (or more if needed) of these bits can be
designated for the RLP field. Since the BGPsec protocol designated for the RLP field. Since the BGPsec protocol
specification requires a sending AS to include the Flags field in the specification requires a sending AS to include the Flags field in the
data that are signed over, the RLP field for each hop (assuming it data that are signed over, the RLP field for each hop (assuming it
would be part of the Flags field) will be protected under the sending would be part of the Flags field) will be protected under the sending
AS's signature. AS's signature.
3.2. Recommended Actions at a Receiving Router for Detection of Route 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 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 peer.
Addionally, 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
Leaks Leaks
We provide here an example set of receiver actions that work to An example set of receiver actions that work to detect and mitigate
detect and mitigate route leaks of Types 1, 2, 3, and 4. This route leaks of Types 1, 2, 3, and 4 are provided here. This example
example algorithm serves as a proof of concept. However, other algorithm serves as a proof of concept. However, other receiver
receiver algorithms or procedures can be designed (based on the same algorithms or procedures can be designed (based on the same sender
sender specification as in Section 3.1) and may perform with greater specification as in Section 3.1) and may perform with greater
efficacy, and are by no means excluded. efficacy, and are by no means excluded.
A recommended receiver algorithm for detecting a route leak is as A recommended receiver algorithm for detecting a route leak is as
follows: follows:
A receiving router SHOULD mark an update as a 'Route Leak' if ALL of A receiving router SHOULD 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 '01' (i.e. 'Do not Propagate 2. The update has the RLP field set to 1 (i.e. 'Do not Propagate Up
Up or Lateral') indication for one or more hops (excluding the or Lateral') indication for one or more hops (excluding the most
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 said AS for detection
of route leaks. of route leaks. (Note: The utility of RLP value set by the peer
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 3.1) 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 5.1 and Section 5.2).
A receiving router expects the RLP field value for any hop in the AS 3.4. Possible Actions at a Receiving Router for Mitigation
path to be either 00 or 01. However, if a different value (say, 10
or 11) is found in the RLP field, then an error condition will get
flagged, and any further action is TBD.
3.3. 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', then the receiving router SHOULD prefer an alternate
unmarked route if available. unmarked route if available.
o If no alternate unmarked route is available, then the route marked o If no alternate unmarked route is available, then the route marked
as a 'Route Leak' MAY be accepted. as a 'Route Leak' MAY be accepted.
A basic principle here is that the presence of '01' value in the RLP A basic principle here is that if an AS receives and marks a customer
field corresponding to one or more AS hops in the AS path of an route as 'Route Leak', then the AS should override the "prefer
update coming from a customer AS informs a receiving router in a customer route" policy, and instead prefer an alternate 'clean' route
transit-provider AS that a route leak is likely occurring. The learned from another customer, a lateral peer, or a transit provider.
transit-provider AS then overrides the "prefer customer route" This can be implemented by adjusting the local preference for the
policy, and instead prefers an alternate 'clean' route learned from routes in consideration.
another customer, a lateral peer, or a transit provider over the
'marked' route from the customer in question.
4. Stopgap Solution when Only Origin Validation is Deployed 4. Stopgap Solution when Only Origin Validation is Deployed
Here we describe a stopgap method 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
of the ASes in Cust_AS_List may be multi-homed to another ISP and of the ASes in Cust_AS_List may be multi-homed to another ISP and
that is OK.) that is OK.)
skipping to change at page 10, line 39 skipping to change at page 12, line 26
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 5.4).
5. Design Rationale and Discussion 5. Design Rationale and Discussion
In this section, we will try to provide design justifications for the This section provides design justifications for the methodology
methodology specified in Section 3, and also answer some questions specified in Section 3, and also answers some questions that are
that are anticipated or have been raised in IETF IDR/SIDR meetings. anticipated or have been raised in the IETF IDR and SIDR working
group meetings.
5.1. Is route-leak solution without cryptographic protection a serious 5.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 bits 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
skipping to change at page 11, line 21 skipping to change at page 13, line 8
maliciously manipulating the RLP bits in an implementation without maliciously manipulating the RLP bits in an implementation without
cryptographic protection (i.e. sans BGPsec). Manipulation of the RLP cryptographic protection (i.e. sans BGPsec). Manipulation of the RLP
bits can result in one of two types of attacks: (a) Upgrade attack bits can result in one of two types of attacks: (a) Upgrade attack
and (b) Downgrade attack. Descriptions and discussions about these and (b) Downgrade attack. Descriptions and discussions about these
attacks follow. In what follows, P2C stands for transit provider to attacks follow. In what follows, P2C stands for transit provider to
customer (Down); C2P stands for customer to transit provider (Up), customer (Down); C2P stands for customer to transit provider (Up),
and p2p stands for peer to peer (lateral or non-transit and p2p stands for peer to peer (lateral or non-transit
relationship). 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 '01' (i.e. would alter the RLP encodings for the preceding hops from 1 (i.e.
'Do not Propagate Up or Lateral') to '00' (default) wherever 'Do not Propagate Up or Lateral') to 0 (default) wherever applicable.
applicable. This poses no problem for a route that keeps propagating This poses no problem for a route that keeps propagating in the
in the 'Down' (P2C) direction. However, for a route that propagates 'Down' (P2C) direction. However, for a route that propagates 'Up'
'Up' (C2P) or 'Lateral' (p2p), the worst that can happen is that a (C2P) or 'Lateral' (p2p), the worst that can happen is that a route
route leak goes undetected. That is, a receiving router would not be leak goes undetected. That is, a receiving router would not be able
able to detect the leak for the route in question by the RLP to detect the leak for the route in question by the RLP mechanism
mechanism described here. However, the receiving router may still described here. However, the receiving router may still detect and
detect and mitigate it in some cases by applying other means such as mitigate it in some cases by applying other means such as prefix
prefix filters [RFC7454]. If some malicious leaks go undetected filters [RFC7454]. If some malicious leaks go undetected (when RLP
(when RLP is deployed without BGPsec) that is possibly a small price is deployed without BGPsec) that is possibly a small price to pay for
to pay for the ability to detect the bulk of route leaks that are the ability to detect the bulk of route leaks that are accidental.
accidental.
(b) Downgrade attack: RLP encoding is set to '01' (i.e. 'Do not (b) Downgrade attack: RLP encoding is set to 1 (i.e. 'Do not
Propagate Up or Lateral') when it should be set to '00' (default). Propagate Up or Lateral') when it should be set to 0 (default). This
This would result in a route being mis-detected and marked as a route would result in a route being mis-detected and marked as a route
leak. By default RLP encoding is set to '00', and that helps reduce leak. By default RLP encoding is set to 0, and that helps reduce
errors of this kind (i.e. accidental downgrade incidents). Every AS errors of this kind (i.e. accidental downgrade incidents). Every AS
or ISP wants reachability for prefixes it originates and for its or ISP wants reachability for prefixes it originates and for its
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 '00' to '01' intentionally. If a route leak is detected (due value 0 to 1 intentionally. If a route leak is detected (due to
to intentional or accidental downgrade) by a receiving router, it intentional or accidental downgrade) by a receiving router, it would
would prefer an alternate 'clean' route from a transit provider or prefer an alternate 'clean' route from a transit provider or peer
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 5.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
skipping to change at page 12, line 42 skipping to change at page 14, line 26
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 business models are often 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). The authors in model (see Section 4.3 and SPA-1 data in Figure 2). [Anwar] also
[Anwar] also observe, "it is well known that this model [the basic observes, "it is well known that this model [the basic Gao-Rexford
Gao-Rexford model and some variations of it] fails to capture many model and some variations of it] fails to capture many aspects of the
aspects of the interdomain routing system. These aspects include AS interdomain routing system. These aspects include AS relationships
relationships that vary based on the geographic region or destination that vary based on the geographic region or destination prefix, and
prefix, and traffic engineering via hot-potato routing or load traffic engineering via hot-potato routing or load balancing." So
balancing." So there may be potential for explaining the remaining there may be potential for explaining the remaining (20% or less)
(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 configuring
policies (including per prefix policies, if applicable), and make policies (including per prefix policies, if applicable), and make
proper use of the RLP indications on a per prefix basis. When said proper use of the RLP indications on a per prefix basis. When said
large ISPs participate in this solution deployment, it is envisioned large ISPs participate in this solution deployment, it is envisioned
that they would form a ring of protection against route leaks, and that they would form a ring of protection against route leaks, and
skipping to change at page 13, line 44 skipping to change at page 15, line 32
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
business models are often sent over the same link between ASes. business models are often sent over the same link between ASes.
Also, the success of AS path based ORF depends on whether ASes at all Also, the success of AS path based ORF depends on whether ASes at all
levels of the hierarchy in a CC participate and provide accurate levels of the hierarchy in a CC participate and provide accurate
information (in the ORF messages) about the AS paths they expect to information (in the ORF messages) about the AS paths they expect to
have in their BGP updates. have in their BGP updates.
6. Summary 5.5. Per-Hop RLP Flags or Single RLP Flag per Update?
It should be emphasized once again that the proposed route-leak The route-leak detection and mitigation mechanism described in this
detection method using the RLP encoding is not intended to cover all document is based on setting RLP flags on a per-hop basis. There is
forms of route leaks. However, we feel that the solution covers another possible mechanism based on a single RLP flag per update.
several important types of route leaks, especially considering some
significant route-leak attacks or occurrences that have been
frequently observed in recent years. The solution can be implemented
in BGP without necessarily tying it to BGPsec. The proposed solution
without BGPsec can detect and mitigate accidental route leaks, and
the same with BGPsec can detect and mitigate both accidental and
malicious route leaks. Carrying the proposed RLP encoding in an
optional transitive path attribute in BGP is proposed, but in order
to prevent abuse, the RLP encoding would require cryptographic
protection. Incorporating the RLP encoding in the BGPsec Flags field
is one way of implementing it securely using an already existing
protection mechanism provided in BGPsec path signatures.
7. Security Considerations Method A - Per-Hop RLP Flags: The sender on each hop in the AS path
sets RLP = 1 if sending the update to a cutomer or lateral peer
(regardless of what the previous ASes in the path set their bits to).
No AS (if operating correctly) would rewrite/reset the RLP flags set
by any preceding AS (see Section 3.1).
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)
determines that it is sending an update towards a customer or lateral
peer AS, it sets the RLP flag. Once the flag is set, it would be
required that subsequent ASes in the path should always leave the
flag set.
Method B is functionally deficient when compared to Method A for
detection of route leaks. This becomes quite evident from the
illustration in Figure 3. With Method B in use, it is evident that
when AS3 receives an update, {p [AS2, AS1] RLP =1] from AS2, there is
no way for it (AS3) to distinguish and tell if AS2 is leaking a route
learned from a transit-provider or lateral peer (AS1), or
legitimately forwarding a route learned from a customer (AS1).
Method A does not suffer from this inadequacy because if Method A
were used, then AS3 in Figure 3 will have the benefit of seeing the
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 +-----+
p--| AS1 |-------->| AS2 |----------------------------->| AS3 |
+-----+ +-----+ Update --> +-----+
Method B: {p [AS2 AS1] RLP=1}
(independent of AS1's relationship with AS2)
** Method B fails to differentiate leak versus legitimate
Method A: {p [AS2 AS1] {RLP2=1 RLP1=1}} -- route leak
(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.
In general, Method A is more robust than Method B in the presence of
faulty operation (including route leaks) or lack of upgrade (to
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
RLP encoding in the case Method A with the help of the BGPsec
protocol (see Section 3.1.2). Method B is not amenable to be mapped
into BGPsec.
6. 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].
8. IANA Considerations 7. IANA Considerations
No updates to the registries are suggested by this document. A request will be made to IANA for assignment of an attribute type
code for the proposed new BGP RLP attribute.
9. Acknowledgements 8. Acknowledgements
The authors wish to thank Danny McPherson and Eric Osterweil for The authors wish to thank Danny McPherson and Eric Osterweil for
discussions related to this work. Also, thanks are due to Jared discussions related to this work. Also, thanks are due to Jared
Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff
Huston, Randy Bush, Ruediger Volk, Sue Hares, Wes George, Chris Huston, Randy Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes
Morrow, and Sandy Murphy for comments, suggestions, and critique. George, Chris Morrow, and Sandy Murphy for comments, suggestions, and
The authors are also thankful to Padma Krishnaswamy, Oliver Borchert, critique. The authors are also thankful to Padma Krishnaswamy,
and Okhee Kim for their comments and review. Oliver Borchert, and Okhee Kim for their comments and review.
10. References 9. References
10.1. Normative References 9.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>.
10.2. Informative References 9.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 16, line 27 skipping to change at page 19, line 9
<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] [I-D.ietf-grow-route-leak-problem-definition]
Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 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", draft-ietf-grow-route-leak-problem- BGP Route Leaks", draft-ietf-grow-route-leak-problem-
definition-04 (work in progress), February 2016. definition-06 (work in progress), May 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPsec Protocol Specification", draft-ietf- Lepinski, M. and K. Sriram, "BGPsec Protocol
sidr-bgpsec-protocol-14 (work in progress), December 2015. Specification", draft-ietf-sidr-bgpsec-protocol-15 (work
in progress), March 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 18, line 19 skipping to change at page 21, line 5
[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>.
[Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.
Robachevsky , "Methods for Detection and Mitigation of BGP
Route Leaks", IETF-95 IDR WG Meeting), April 2016,
<https://www.ietf.org/proceedings/95/slides/slides-95-idr-
13.pdf>.
[Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August
2014, <http://www.bgpmon.net/ 2014, <http://www.bgpmon.net/
what-caused-todays-internet-hiccup/>. what-caused-todays-internet-hiccup/>.
[Toonk2015-A] [Toonk2015-A]
Toonk, A., "What caused the Google service interruption", Toonk, A., "What caused the Google service interruption",
March 2015, <http://www.bgpmon.net/ March 2015, <http://www.bgpmon.net/
what-caused-the-google-service-interruption/>. what-caused-the-google-service-interruption/>.
[Toonk2015-B] [Toonk2015-B]
 End of changes. 43 change blocks. 
202 lines changed or deleted 333 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/