draft-ietf-idr-route-leak-detection-mitigation-01.txt   draft-ietf-idr-route-leak-detection-mitigation-02.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: April 21, 2016 B. Dickson Expires: September 15, 2016 B. Dickson
K. Patel K. Patel
Cisco Cisco
A. Robachevsky A. Robachevsky
Internet Society Internet Society
October 19, 2015 March 14, 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-01 draft-ietf-idr-route-leak-detection-mitigation-02
Abstract Abstract
In [I-D.ietf-grow-route-leak-problem-definition], the authors have In [I-D.ietf-grow-route-leak-problem-definition], the authors have
provided a definition of the route leak problem, and also enumerated provided a definition of the route leak problem, and also enumerated
several types of route leaks. In this document, we first examine several types of route leaks. In this document, we first examine
which of those route-leak types are detected and mitigated by the which of those route-leak types are detected and mitigated by the
existing origin validation (OV) [RFC 6811] and BGPSEC path validation existing origin validation (OV) [RFC 6811]. It is recognized that OV
[I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC offers a limited detection and mitigation capability against route
protocols don't offer a solution, this document suggests an leaks. This document proposes an enhancement that significantly
enhancement that would extend the route-leak detection and mitigation extends the route-leak detection and mitigation capabilities of BGP.
capability of BGPSEC. The solution can be implemented in BGP without The solution involves carrying a per-hop route-leak protection (RLP)
necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC field in BGP updates. The RLP field is proposed be carried in an
is one way of implementing it in a secure way. We do not claim to optional transitive path attribute. The solution is meant to be
have provided a solution for all possible types of route leaks, but initially implemented as an enhancement of BGP without requiring
the solution covers several, especially considering some significant BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is
route-leak attacks or occurrences that have been observed in recent deployed in the future, the solution can be incorporated in BGPsec,
enabling cryptographic protection for the RLP field. That would be
one way of implementing the proposed solution in a secure way. It is
not 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 for detection and years. The document also includes a stopgap method for detection and
mitigation of route leaks for the phase when BGPSEC (path validation) mitigation of route leaks for an intermediate phase when OV is
is not yet deployed but only origin validation is deployed. 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 April 21, 2016. This Internet-Draft will expire on September 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
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 . . . . . . . . . . . . . . . . . . . . . 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.2. Recommended Actions at a Receiving Router for Detection
of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8
3.3. Possible Actions at a Receiving Router for Mitigation . . 9 3.3. Possible Actions at a Receiving Router for Mitigation . . 9
4. Stopgap Solution when Only Origin Validation is Deployed . . 9 4. Stopgap Solution when Only Origin Validation is Deployed . . 9
5. Design Rationale and Discussion . . . . . . . . . . . . . . . 10 5. Design Rationale and Discussion . . . . . . . . . . . . . . . 10
5.1. Is route-leak solution without BGPSEC a serious attack 5.1. Is route-leak solution without cryptographic protection a
vector? . . . . . . . . . . . . . . . . . . . . . . . . . 10 serious attack vector? . . . . . . . . . . . . . . . . . 10
5.2. Are there cases when valley-free violations can be 5.2. Combining results of route-leak detection, OV and BGPsec
validation for path selection decision . . . . . . . . . 12
5.3. Are there cases when valley-free violations can be
considered legitimate? . . . . . . . . . . . . . . . . . 12 considered legitimate? . . . . . . . . . . . . . . . . . 12
5.3. Comparison with other methods, routing security BCP . . . 12 5.4. Comparison with other methods, routing security BCP . . . 13
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In [I-D.ietf-grow-route-leak-problem-definition], the authors have In [I-D.ietf-grow-route-leak-problem-definition], the authors have
provided a definition of the route leak problem, and also enumerated provided a definition of the route leak problem, and also enumerated
several types of route leaks. In this document, we first examine several types of route leaks. In this document, we first examine
which of those route-leak types are detected and mitigated by the which of those route-leak types are detected and mitigated by the
existing Origin Validation (OV) [RFC6811] and BGPSEC path validation existing Origin Validation (OV) [RFC6811] method. OV and BGPsec path
[I-D.ietf-sidr-bgpsec-protocol]. For the rest of this document, we validation [I-D.ietf-sidr-bgpsec-protocol] together offer mechanisms
use the term BGPSEC as synonymous with path validation. The BGPSEC to protect against re-originations and hijacks of IP prefixes as well
protocol provides cryptographic protection for some aspects of BGP as man-in-the-middle (MITM) AS path modifications. Route leaks (see
update messages. OV and BGPSEC together offer mechanisms to protect
against re-originations and hijacks of IP prefixes as well as man-in-
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 and BGPSEC so far offer only partial system against which OV offers only partial protection. BGPsec (i.e.
protection. path validation) provides cryptographic protection for some aspects
of BGP update messages, but in its current form BGPsec doesn't offer
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 current OV
and BGPSEC protocols don't offer a solution, this document suggests method does't offer a solution, this document proposes an enhancement
an enhancement that would extend the detection and mitigation that would significantly extend the detection and mitigation
capability of BGPSEC. The solution can be implemented in BGP without capabilities of BGP. The solution involves carrying a per-hop route-
necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC leak protection (RLP) field in BGP updates. The RLP field is
is one way of implementing it in a secure way. We do not claim to proposed be carried in an optional transitive path attribute. The
provide a solution for all possible types of route leaks, but the solution is meant to be initially implemented as an enhancement of
solution covers several relevant types, especially considering some BGP without requiring BGPsec. However, when BGPsec is deployed in
significant route-leak occurrences that have been observed frequently the future, the solution can be incorporated in BGPsec, enabling
in recent years. The document also includes (in Section 4) a stopgap cryptographic protection for the RLP field. That would be one way of
method for detection and mitigation of route leaks for the phase when implementing the proposed solution in a secure way. It is not
BGPSEC (path validation) is not yet deployed but only origin claimed that the solution detects all possible types of route leaks
validation is deployed. 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 4) 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 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. Dickson developed the initial Internet draft of
these mechanisms in a BGPSEC context; see these mechanisms in a BGPsec context; see
[draft-dickson-sidr-route-leak-solns]. The draft expired in 2012. [draft-dickson-sidr-route-leak-solns]. The draft expired in 2012.
[draft-dickson-sidr-route-leak-solns] defined neighbor relationships [draft-dickson-sidr-route-leak-solns] defined neighbor relationships
on a per link basis, but in the current draft the relationship in on a per link basis, but in the current draft the relationship is
encoded per prefix, as routes for prefixes with different business encoded per prefix, as routes for prefixes with 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 draft when BGPsec-based
solution is considered, cryptographic protection is provided for solution is considered, cryptographic protection is provided for
Route Leak Protection (RLP) encoding using the same signature block Route-Leak Protection (RLP) encoding using the same signature block
as that for path signatures (see Section 3.1). 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
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 even by BGPSEC. Type 5 route leak involves detected by OV or BGPsec in its current form. Clearly, Type 5 route
changing a prefix to a more specific; such a modified update will leak involves re-origination or hijacking, and hence can be detected
fail BGPSEC checks. Clearly, Type 6 route leak involves re- by OV. In the case of Type 5 route leak, there would be no existing
origination or hijacking, and hence can be detected by OV. In the ROAs to validate a re-originated prefix or more specific, but instead
case of Type 6 route leak, there would be no existing ROAs to a covering ROA would normally exist with the legitimate AS, and hence
validate a re-originated prefix or more specific, but instead 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.
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Type of Route Leak | Detection Coverage and Comments | | Type of Route Leak | Current State of Detection |
| | Coverage |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Type 1: U-Shaped Turn with Full | Neither OV nor BGPSEC (in its | | Type 1: Hairpin Turn with Full | Neither OV nor BGPsec (in its |
| Prefix | current form) detects Type 1. | | Prefix | current form) detects Type 1. |
| ------------------------------- | ------------------------------- | | ------------------------------- | ------------------------------- |
| Type 2: Lateral ISP-ISP-ISP | Neither OV nor BGPSEC (in its | | Type 2: Lateral ISP-ISP-ISP | Neither OV nor BGPsec (in its |
| Leak | current form) detects Type 2. | | Leak | current form) detects Type 2. |
| ------------------------------- | ------------------------------- | | ------------------------------- | ------------------------------- |
| Type 3: Leak of Transit- | Neither OV nor BGPSEC (in its | | Type 3: Leak of Transit- | Neither OV nor BGPsec (in its |
| Provider Prefixes to Peer | current form) detects Type 3. | | Provider Prefixes to Peer | current form) detects Type 3. |
| ------------------------------- | ------------------------------- | | ------------------------------- | ------------------------------- |
| Type 4: Leak of Peer Prefixes | Neither OV nor BGPSEC (in its | | Type 4: Leak of Peer Prefixes | Neither OV nor BGPsec (in its |
| to Transit Provider | current form) detects Type 4. | | to Transit Provider | current form) detects Type 4. |
| ------------------------------- | ------------------------------- | | ------------------------------- | ------------------------------- |
| Type 5: U-Shaped Turn with More | In OV, the ROA maxLength may | | Type 5: Prefix Re-Origination | OV detects Type 5. |
| Specific Prefix | offer detection of Type 5 in | | with Data Path to Legitimate | |
| | some cases; BGPSEC (in its |
| | current form) always detects |
| | Type 5. |
| ------------------------------- | ------------------------------- |
| Type 6: Prefix Re-Origination | OV by itself detects Type 6; |
| with Data Path to Legitimate | BGPSEC does not detect Type 6. |
| Origin | | | Origin | |
| ------------------------------- | ------------------------------- | | ------------------------------- | ------------------------------- |
| Type 7: Accidental Leak of | For internal prefixes never | | Type 6: Accidental Leak of | For internal prefixes never |
| Internal Prefixes and More | meant to be seen (i.e. routed) | | Internal Prefixes and More | meant to be routed on the |
| Specifics | on the Internet, OV helps | | Specifics | Internet, OV helps detect their |
| | detect their leak; they might | | | leak; they might either have no |
| | either have no covering ROA or | | | covering ROA or have an AS0-ROA |
| | have an AS0-ROA to always | | | to always filter them. In the |
| | filter them. In the case of | | | case of accidental leak of more |
| | accidental leak of more |
| | specifics, OV may offer some | | | specifics, OV may offer some |
| | detection due to ROA maxLength. | | | detection due to ROA maxLength. |
| | BGPSEC does not catch Type 7. |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
Table 1: Examination of Route-Leak Detection Capability of Origin Table 1: Examination of Route-Leak Detection Capability of Origin
Validation and Current BGPSEC Path Validation Validation and Current BGPsec Path Validation
In the case of Type 7 leaks involving internal prefixes that are not In the case of Type 6 leaks involving internal prefixes that are not
meant to be routed in the Internet, they are likely to be detected by meant to be routed in the Internet, they are likely to be detected by
OV. That is because such prefixes might either have no covering ROA OV. That is because such prefixes might either have no covering ROA
or have an AS0-ROA to always filter them. In the case of Type 7 or have an AS0-ROA to always filter them. In the case of Type 6
leaks that are due to accidental leak of more specifics, they may be leaks that are due to accidental leak of more specifics, they may be
detected due to violation of ROA maxLength. BGPSEC does not catch detected due to violation of ROA maxLength. BGPsec (i.e. path
Type 7. However, route leaks of Type 7 are least problematic due to validation) in its current form does not detect Type 6. However,
the following reasons. In the case of leak of more specifics, the route leaks of Type 6 are least problematic due to the following
offending AS is itself the legitimate destination of the leaked more- reasons. In the case of leak of more specifics, the offending AS is
specific prefixes. Hence, in most cases of this type, the data itself the legitimate destination of the leaked more-specific
traffic is neither misrouted not denied service. Also, leaked prefixes. Hence, in most cases of this type, the data traffic is
announcements of Type 7 are short-lived and typically withdrawn neither misrouted not denied service. Also, leaked announcements of
quickly following the announcements. Further, the MaxPrefix limit Type 6 are short-lived and typically withdrawn quickly following the
may kick-in in some receiving routers and that helps limit the announcements. Further, the MaxPrefix limit may kick-in in some
propagation of sometimes large number of leaked routes of Type 7. receiving routers and that helps limit the propagation of sometimes
large number of leaked routes of Type 6.
Realistically, BGPSEC may take a much longer time being deployed than 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 in our proposed solution method, we need
to focus primarily on route leaks of Types 1, 2, 3, 4, and 5. In to focus primarily on route leaks of Types 1, 2, 3, and 4. In
Section 3.1 and Section 3.2, we describe a simple addition to BGP Section 3.1 and Section 3.2, we describe a simple addition to BGP
that facilitates detection of route leaks of Types 1, 2, 3, 4, and 5. that facilitates detection of route leaks of Types 1, 2, 3, and 4.
The simple addition involves a Route Leak Protection (RLP) field, The simple addition involves a Route-Leak Protection (RLP) field,
which is carried in an optional transitive path attribute in BGP. which is carried in an optional transitive path attribute in BGP.
When BGPSEC is deployed, the RLP field will be accommodated in the When BGPsec is deployed, the RLP field will be accommodated in the
existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is
cryptographically protected under path signatures. cryptographically protected under path signatures.
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,
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
Protection (RLP) field to be set by a sending router is proposed to Protection (RLP) field to be set by a sending router is proposed to
be used for each AS hop. be used for each AS hop.
/\ /\ /\ /\
\ route-leak(P)/ \ route-leak(P)/
\ propagated / \ propagated /
\ / \ /
+------------+ peer +------------+ +------------+ peer +------------+
______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> ______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
/ ------------+ prefix(P) +------------+ route-leak(P) / ------------+ prefix(P) +------------+ route-leak(P)
skipping to change at page 7, line 24 skipping to change at page 7, line 24
------- prefix(P) \ / \ ------- prefix(P) \ / \
update \ / \ update \ / \
\ /route-leak(P) \/ \ /route-leak(P) \/
\/ / \/ /
+---------------+ +---------------+
| customer(AS3) | | customer(AS3) |
+---------------+ +---------------+
Figure 1: Illustration of the basic notion of a route leak. Figure 1: Illustration of the basic notion of a route leak.
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 00: This is the default value (i.e. "nothing specified"),
o 01: This is the 'Do not Propagate Up or Lateral' indication; o 01: This is the 'Do not Propagate Up or Lateral' indication;
sender indicating that the route SHOULD NOT be forwarded 'Up' sender indicating that the route SHOULD NOT be forwarded 'Up'
towards a transit-provider AS or to a lateral (i.e. non-transit) towards a transit-provider AS or to a lateral (i.e. non-transit)
peer AS. peer AS.
skipping to change at page 8, line 4 skipping to change at page 8, line 4
non-transit) AS. In essence, in both scenarios, the intent of '01' non-transit) AS. In essence, in both scenarios, the intent of '01'
indication is that the neighbor AS and any receiving AS along the indication is that the neighbor AS and any receiving AS along the
subsequent AS path SHOULD NOT forward the update 'Up' towards its subsequent AS path SHOULD NOT forward the update 'Up' towards its
(receiving AS's) transit-provider AS or laterally towards its peer (receiving AS's) transit-provider AS or laterally towards its peer
(i.e. non-transit) AS. When sending an update 'Up' to a transit- (i.e. non-transit) AS. When sending an update 'Up' to a transit-
provider AS, the RLP encoding should be set to the default value of provider AS, the RLP encoding should be set to the default value of
'00'. When a sending AS sets the RLP encoding to '00', it is '00'. When a sending AS sets the RLP encoding to '00', it is
indicating to the receiving AS that the update can be propagated in indicating to the receiving AS that the update can be propagated in
any direction (i.e. towards transit-provider, customer, or lateral any direction (i.e. towards transit-provider, customer, or lateral
peer). This two-state specification in the RLP field can be shown to peer). This two-state specification in the RLP field can be shown to
work for detection and mitigation of route leaks of Types 1, 2, 3, 4, work for detection and mitigation of route leaks of Types 1, 2, 3,
and 5, which are the focus here (see Section 3.2 and Section 3.3). and 4 which are the focus here (see Section 3.2 and Section 3.3).
The '10' and '11' values in the RLP field (assuming that two bits are The '10' and '11' values in the RLP field (assuming that two bits are
used to encode it) are currently unassigned, and reserved for used to encode it) are currently unassigned, and reserved for
possible future use. possible future use.
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 an optional transitive path attribute. In BGPsec enabled
routers, the RLP encoding SHOULD be accommodated in the existing routers, the RLP encoding SHOULD be accommodated in the existing
Flags field in BGPSEC updates. The Flags field is part of the Flags field in BGPsec updates. The Flags field is part of the
Secure_Path Segment in BPGSEC updates 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. Recommended Actions at a Receiving Router for Detection of Route
Leaks Leaks
We provide here an example set of receiver actions that work to We provide here an example set of receiver actions that work to
detect and mitigate route leaks of Types 1, 2, 3, 4, and 5. This detect and mitigate route leaks of Types 1, 2, 3, and 4. This
example algorithm serves as a proof of concept. However, other example algorithm serves as a proof of concept. However, other
receiver algorithms or procedures can be designed (based on the same receiver algorithms or procedures can be designed (based on the same
sender specification as in Section 3.1) and may perform with greater sender 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. It is Valid in accordance with the Origin Validation (OV) and 2. The update has the RLP field set to '01' (i.e. 'Do not Propagate
BGPSEC protocols. (Note: BGPSEC validation is not applicable if
update is not signed.)
3. The update has the RLP field set to '01' (i.e. 'Do not Propagate
Up or Lateral') indication for one or more hops (excluding the Up or Lateral') indication for one or more hops (excluding the
most recent) in the AS path. most 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.
If the RLP encoding is secured by BGPsec (see Section 3.1) and hence
protected against tampering by intermediate ASes, then there would be
added certainty in the route-leak detection algorithm described above
(see discussions in Section 5.1 and Section 5.2).
A receiving router expects the RLP field value for any hop in the AS A receiving router expects the RLP field value for any hop in the AS
path to be either 00 or 01. However, if a different value (say, 10 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 or 11) is found in the RLP field, then an error condition will get
flagged, and any further action is TBD. flagged, and any further action is TBD.
3.3. Possible Actions at a Receiving Router for Mitigation 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 the presence of '01' value in the RLP
field corresponding to one or more AS hops in the AS path of an field corresponding to one or more AS hops in the AS path of an
update coming from a customer AS informs a receiving router in a update coming from a customer AS informs a receiving router in a
transit-provider AS that a route leak is likely occurring. The transit-provider AS that a route leak is likely occurring. The
transit-provider AS then overrides the "prefer customer route" transit-provider AS then overrides the "prefer customer route"
policy, and instead prefers an alternate 'clean' route learned from policy, and instead prefers an alternate 'clean' route learned from
another customer, a lateral peer, or a transit provider over the another customer, a lateral peer, or a transit provider over the
'marked' route from the customer in question. '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
During a phase when BGPSEC path validation has not yet been deployed Here we describe a stopgap method for detection and mitigation of
but only origin validation has been deployed, it would be good have a route leaks for the intermediate phase when OV is deployed but BGP
stopgap solution for route leaks. The stopgap solution can be in the protocol on the wire is unchanged. The stopgap solution can be in
form of construction of a prefix filter list from ROAs. A suggested the form of construction of a prefix filter list from ROAs. A
procedure for constructing such a list comprises of the following suggested procedure for constructing such a list comprises of the
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.)
o ISP downloads from the RPKI repositories a complete list o ISP downloads from the RPKI repositories a complete list
(Cust_ROA_List) of valid ROAs that contain any of the ASes in (Cust_ROA_List) of valid ROAs that contain any of the ASes in
Cust_AS_List. Cust_AS_List.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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.3). 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 In this section, we will try to provide design justifications for the
methodology specified in Section 3, and also answer some questions methodology specified in Section 3, and also answer some questions
that are anticipated or have been raised in IETF IDR/SIDR meetings. that are anticipated or have been raised in IETF IDR/SIDR meetings.
5.1. Is route-leak solution without BGPSEC a serious attack vector? 5.1. Is route-leak solution without cryptographic protection a serious
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. That 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 bits in an implementation without
BGPSEC. Manipulation of the RLP bits can result in one of two types cryptographic protection (i.e. sans BGPsec). Manipulation of the RLP
of attacks: (a) Upgrade attack and (b) Downgrade attack. bits can result in one of two types of attacks: (a) Upgrade attack
Descriptions and discussions about these attack follow. In what and (b) Downgrade attack. Descriptions and discussions about these
follows, P2C stands for transit provider to customer (Down); C2P attacks follow. In what follows, P2C stands for transit provider to
stands for customer to transit provider (Up), and p2p stands for peer customer (Down); C2P stands for customer to transit provider (Up),
to peer (lateral or non-transit relationship). and p2p stands for peer to peer (lateral or non-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 '01' (i.e. would alter the RLP encodings for the preceding hops from '01' (i.e.
'Do not Propagate Up or Lateral') to '00' (default) wherever 'Do not Propagate Up or Lateral') to '00' (default) wherever
applicable. This poses no problem for a route that keeps propagating applicable. This poses no problem for a route that keeps propagating
in the 'Down' (P2C) direction. However, for a route that propagates in the 'Down' (P2C) direction. However, for a route that propagates
'Up' (C2P) or 'Lateral' (p2p), the worst that can happen is that a 'Up' (C2P) or 'Lateral' (p2p), the worst that can happen is that a
route leak goes undetected. That is, a receiving router would not be route leak goes undetected. That is, a receiving router would not be
able to detect the leak for the route in question by the RLP able to detect the leak for the route in question by the RLP
mechanism described here. However, the receiving router may still mechanism described here. However, the receiving router may still
detect and mitigate it in some cases by applying other means such as detect and mitigate it in some cases by applying other means such as
prefix filters [RFC7454]. If some malicious leaks go undetected prefix filters [RFC7454]. If some malicious leaks go undetected
(when RLP is deployed without BGPSEC) that is possibly a small price (when RLP is deployed without BGPsec) that is possibly a small price
to pay for the ability to detect the bulk of route leaks that are to pay for 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 '01' (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 '00' (default).
This would result in a route being mis-detected and marked as a route This 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 '00', 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 '00' to '01' intentionally. If a route leak is detected (due
to intentional or accidental downgrade) by a receiving router, it to intentional or accidental downgrade) by a receiving router, it
would prefer an alternate 'clean' route from a transit provider or would prefer an alternate 'clean' route from a transit provider or
peer over a 'marked' route from a customer. It may end up with a peer 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. Are there cases when valley-free violations can be considered 5.2. Combining results of route-leak detection, OV and BGPsec
validation for path selection decision
Combining the results of route-leak detection, OV, and BGPsec
validation for path selection decision is up to local policy in a
receiving router. As an example, a router may always give precedence
to outcomes of OV and BGPsec validation over that of route-leak
detection. That is, if an update fails OV or BGPsec validation, then
the update is not considered a candidate for path selection.
Instead, an alternate update is chosen that passed OV and BGPsec
validation and additionally was not marked as route leak.
If only OV is deployed (and not BGPsec), then there are six possible
combinations between OV and route-leak detection outcomes. Because
there are three possible outcomes for OV (NotFound, Valid, and
Invalid) and two possible outcomes for route-leak detection (marked
as leak and not marked). If OV and BGPsec are both deployed, then
there are twelve possible combinations between OV, BGPsec validation,
and route-leak detection outcomes. As stated earlier, since BGPsec
protects the RLP encoding, there would be added certainty in route-
leak detection outcome if an update is BGPsec valid (see
Section 5.1).
5.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 business models are often sent over the same link.
skipping to change at page 12, line 29 skipping to change at page 12, line 52
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). The authors in
[Anwar] also observe, "it is well known that this model [the basic [Anwar] also observe, "it is well known that this model [the basic
Gao-Rexford model and some variations of it] fails to capture many Gao-Rexford model and some variations of it] fails to capture many
aspects of the interdomain routing system. These aspects include AS aspects of the interdomain routing system. These aspects include AS
relationships that vary based on the geographic region or destination relationships that vary based on the geographic region or destination
prefix, and traffic engineering via hot-potato routing or load prefix, and traffic engineering via hot-potato routing or load
balancing." So there may be potential for explaining the remaining balancing." So there may be potential for explaining the remaining
(20% or less) violations of valley-free as well. (20% or less) 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
co-operatively avoid many of the common types of route leaks that are co-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.3. Comparison with other methods, routing security BCP 5.4. Comparison with other methods, routing security BCP
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
skipping to change at page 13, line 29 skipping to change at page 14, line 4
have in their BGP updates. have in their BGP updates.
6. Summary 6. Summary
It should be emphasized once again that the proposed route-leak It should be emphasized once again that the proposed route-leak
detection method using the RLP encoding is not intended to cover all detection method using the RLP encoding is not intended to cover all
forms of route leaks. However, we feel that the solution covers forms of route leaks. However, we feel that the solution covers
several important types of route leaks, especially considering some several important types of route leaks, especially considering some
significant route-leak attacks or occurrences that have been significant route-leak attacks or occurrences that have been
frequently observed in recent years. The solution can be implemented frequently observed in recent years. The solution can be implemented
in BGP without necessarily tying it to BGPSEC. The proposed solution in BGP without necessarily tying it to BGPsec. The proposed solution
without BGPSEC can detect and mitigate accidental route leaks, and without BGPsec can detect and mitigate accidental route leaks, and
the same with BGPSEC can detect and mitigate both accidental and the same with BGPsec can detect and mitigate both accidental and
malicious route leaks. Carrying the proposed RLP encoding in an malicious route leaks. Carrying the proposed RLP encoding in an
optional transitive path attribute in BGP is proposed, but in order optional transitive path attribute in BGP is proposed, but in order
to prevent abuse, the RLP encoding would require cryptographic to prevent abuse, the RLP encoding would require cryptographic
protection. Incorporating the RLP encoding in the BGPSEC Flags field protection. Incorporating the RLP encoding in the BGPsec Flags field
is one way of implementing it securely using an already existing is one way of implementing it securely using an already existing
protection mechanism provided in BGPSEC path signatures. protection mechanism provided in BGPsec path signatures.
7. Security Considerations 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 BPGSEC 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 8. IANA Considerations
No updates to the registries are suggested by this document. No updates to the registries are suggested by this document.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank Danny McPherson and Eric Osterweil for The authors wish to thank Danny McPherson and Eric Osterweil for
skipping to change at page 15, line 50 skipping to change at page 16, line 27
<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-03 (work in progress), October 2015. definition-04 (work in progress), February 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPsec Protocol Specification", draft-ietf- Lepinski, M., "BGPsec Protocol Specification", draft-ietf-
sidr-bgpsec-protocol-13 (work in progress), July 2015. sidr-bgpsec-protocol-14 (work in progress), December 2015.
[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",
ThousandEyes Blog, June 2015,
<https://blog.thousandeyes.com/route-leak-causes-amazon-
and-aws-outage>.
[Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix
Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA,
November 2012, <http://www.cs.arizona.edu/~bzhang/ November 2012, <http://www.cs.arizona.edu/~bzhang/
paper/12-imc-hijack.pdf>. paper/12-imc-hijack.pdf>.
[Labovitz] [Labovitz]
Labovitz, C., "Additional Discussion of the April China Labovitz, C., "Additional Discussion of the April China
BGP Hijack Incident", Arbor Networks IT Security Blog, BGP Hijack Incident", Arbor Networks IT Security Blog,
November 2010, November 2010,
<http://www.arbornetworks.com/asert/2010/11/additional- <http://www.arbornetworks.com/asert/2010/11/additional-
 End of changes. 72 change blocks. 
153 lines changed or deleted 186 lines changed or added

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