draft-ietf-idr-route-leak-detection-mitigation-03.txt   draft-ietf-idr-route-leak-detection-mitigation-04.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: November 24, 2016 B. Dickson Expires: January 9, 2017 B. Dickson
K. Patel K. Patel
Cisco Cisco
A. Robachevsky A. Robachevsky
Internet Society Internet Society
May 23, 2016 July 8, 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-03 draft-ietf-idr-route-leak-detection-mitigation-04
Abstract Abstract
[I-D.ietf-grow-route-leak-problem-definition] provides a definition [I-D.ietf-grow-route-leak-problem-definition] provides a definition
of the route leak problem, and also enumerates several types of route of the route leak problem, and also enumerates several types of route
leaks. This document first examines which of those route-leak types leaks. This document first examines which of those route-leak types
are detected and mitigated by the existing origin validation (OV) are detected and mitigated by the existing origin validation (OV)
[RFC 6811]. It is recognized that OV offers a limited detection and [RFC 6811]. It is recognized that OV offers a limited detection and
mitigation capability against route leaks. This document specifies mitigation capability against route leaks. This document specifies
enhancements that significantly extend the route-leak prevention, enhancements that significantly extend the route-leak prevention,
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 November 24, 2016. This Internet-Draft will expire on January 9, 2017.
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 45 skipping to change at page 2, line 45
3.1.2. Carrying RLP Flag Values in the BGPsec Flags . . . . 9 3.1.2. Carrying RLP Flag Values in the BGPsec Flags . . . . 9
3.2. Intra-AS Messaging for Route Leak Prevention . . . . . . 9 3.2. Intra-AS Messaging for Route Leak Prevention . . . . . . 9
3.3. Recommended Actions at a Receiving Router for Detection 3.3. Recommended Actions at a Receiving Router for Detection
of Route Leaks . . . . . . . . . . . . . . . . . . . . . 10 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 10
3.4. Possible Actions at a Receiving Router for Mitigation . . 11 3.4. Possible Actions at a Receiving Router for Mitigation . . 11
4. Stopgap Solution when Only Origin Validation is Deployed . . 11 4. Stopgap Solution when Only Origin Validation is Deployed . . 11
5. Design Rationale and Discussion . . . . . . . . . . . . . . . 12 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? . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . 13 validation for path selection decision . . . . . . . . . 14
5.3. Are there cases when valley-free violations can be 5.3. Are there cases when valley-free violations can be
considered legitimate? . . . . . . . . . . . . . . . . . 14 considered legitimate? . . . . . . . . . . . . . . . . . 14
5.4. Comparison with other methods, routing security BCP . . . 15 5.4. Comparison with other methods, routing security BCP . . . 15
5.5. Per-Hop RLP Flags or Single RLP Flag per Update? . . . . 15 5.5. Per-Hop RLP Flags or Single RLP Flag per Update? . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[I-D.ietf-grow-route-leak-problem-definition] provides a definition [I-D.ietf-grow-route-leak-problem-definition] provides a definition
of the route leak problem, and also enumerates several types of route of the route leak problem, and also enumerates several types of route
leaks. This document first examines which of those route-leak types leaks. This document first examines which of those route-leak types
are detected and mitigated by the existing Origin Validation (OV) are detected and mitigated by the existing Origin Validation (OV)
[RFC6811] method. OV and BGPsec path validation [RFC6811] method. OV and BGPsec path validation
[I-D.ietf-sidr-bgpsec-protocol] together offer mechanisms to protect [I-D.ietf-sidr-bgpsec-protocol] together offer mechanisms to protect
against re-originations and hijacks of IP prefixes as well as man-in- against re-originations and hijacks of IP prefixes as well 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 OV method [I-D.ietf-grow-route-leak-problem-definition], where the OV method
does't offer a solution, this document specifies enhancements that does not offer a solution, this document specifies enhancements that
significantly extend the route-leak prevention, detection, and significantly extend the route-leak prevention, detection, and
mitigation capabilities of BGP. One solution component involves mitigation capabilities of BGP. One solution component involves
carrying a per-hop route-leak protection (RLP) field in BGP updates. carrying a per-hop route-leak protection (RLP) field in BGP updates.
The RLP field is proposed be carried in a new optional transitive The RLP field is proposed be carried in a new optional transitive
attribute, called BGP RLP attribute. The solution is meant to be attribute, called BGP RLP attribute. The solution is meant to be
initially implemented as an enhancement of BGP without requiring initially implemented as an enhancement of BGP without requiring
BGPsec. However, when BGPsec is deployed in the future, the solution BGPsec. However, when BGPsec is deployed in the future, the solution
can be incorporated in BGPsec, enabling cryptographic protection for can be incorporated in BGPsec, enabling cryptographic protection for
the RLP field. That would be one way of implementing the proposed the RLP field. That would be one way of implementing the proposed
solution in a secure way. It is not claimed that the solution solution in a secure way. It is not claimed that the solution
skipping to change at page 9, line 25 skipping to change at page 9, line 25
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. Intra-AS Messaging for Route Leak Prevention 3.2. Intra-AS Messaging for Route Leak Prevention
The following procedure (or similar) for intra-AS messaging (i.e. The following procedure (or similar) for intra-AS messaging (i.e.
between ingress and egress routers) for prevention of route leaks is between ingress and egress routers) for prevention of route leaks is
a fairly common practice used by large ISPs. (Note: This information a fairly common practice used by large ISPs. (Note: This information
was gathered through private discussions with operators of large ISP was gathered from discussions on the NANOG mailing list
networks.) [Nanog-thread-June2016] as well as through private discussions with
operators of large ISP networks.)
Routes are tagged on ingress to an AS with communities for origin, Routes are tagged on ingress to an AS with communities for origin,
including the type of eBGP peer it was learned from (customer, including the type of eBGP peer it was learned from (customer,
transit-provider or peer), geographic location, etc. The community transit-provider or peer), geographic location, etc. The community
attributes are carried across the AS with the routes. Routes that attributes are carried across the AS with the routes. Routes that
the AS originates directly are tagged with similar origin communities the AS originates directly are tagged with similar origin communities
when they are redistributed into BGP from static, IGP, etc. These when they are redistributed into BGP from static, IGP, etc. These
communities are used along with additional logic in route policies to communities are used along with additional logic in route policies to
determine which routes are to be announced to which eBGP peers and determine which routes are to be announced to which eBGP peers and
which are to be dropped. Route policy is applied to eBGP sessions which are to be dropped. Route policy is applied to eBGP sessions
based on what set of routes they should receive (transit, full based on what set of routes they should receive (transit, full
routes, internal-only, default-only, etc.). In this process, the routes, internal-only, default-only, etc.). In this process, the
ISP's AS also ensures that routes learned from a transit-provider or 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 a lateral peer (i.e. non-transit) at an ingress router are not leaked
at an egress router to another transit-provider or peer. at an egress router to another transit-provider or lateral peer.
Addionally, in many cases, ISP network operators' outbound policies Additionally, in many cases, ISP network operators' outbound policies
require explicit matches for expected communities before passing require explicit matches for expected communities before passing
routes. This helps ensure that that if an update has made it into 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 the routing table (i.e. RIB) but has missed its ingress community
tagging (due to a missing/misapplied ingress policy), it will not be tagging (due to a missing/misapplied ingress policy), it will not be
inadvertently leaked. inadvertently leaked.
The above procedure (or a simplified version of it) is also The above procedure (or a simplified version of it) is also
applicable when an AS consists of a single eBGP router. It is applicable when an AS consists of a single eBGP router. It is
recommended that all AS operators SHOULD implement the procedure recommended that all AS operators SHOULD implement the procedure
described above (or similar that is appropriate for their network) to described above (or similar that is appropriate for their network) to
skipping to change at page 12, line 24 skipping to change at page 12, line 24
originate or announce a DDoS victim's prefix to their own ISP on a originate or announce a DDoS victim's prefix to their own ISP on a
short notice during a DDoS emergency. Some provisions would need to short notice during a DDoS emergency. Some provisions would need to
be made for such cases, and they can be determined with the help of be made for such cases, and they can be determined with the help of
inputs from DDoS mitigation service providers. inputs from DDoS mitigation service providers.
For developing a list of all the ASes (Cust_AS_List) that are in the For developing a list of all the ASes (Cust_AS_List) that are in the
customer cone of an ISP, the AS path based Outbound Route Filter customer cone of an ISP, the AS path based Outbound Route Filter
(ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see (ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see
discussion in Section 5.4). discussion in Section 5.4).
Another technique based on AS_PATH filters is described in
[Snijders]. This method is applicable to very large ISPs (i.e. big
networks) that have lateral peering. For a pair of such very large
ISPs, say A and B, the method depends on ISP A communicating out-of-
band (e.g. by email) with ISP B about whether or not it (ISP A) has
any transit providers. This out-of-band knowledge enables ISP B to
apply suitable AS_PATH filtering criteria for routes involving the
presence of ISP A in the path and prevent certain kinds of route
leaks (see [Snijders] for details).
5. Design Rationale and Discussion 5. Design Rationale and Discussion
This section provides design justifications for the methodology This section provides design justifications for the methodology
specified in Section 3, and also answers some questions that are specified in Section 3, and also answers some questions that are
anticipated or have been raised in the IETF IDR and SIDR working anticipated or have been raised in the IETF IDR and SIDR working
group meetings. group meetings.
5.1. Is route-leak solution without cryptographic protection a serious 5.1. Is route-leak solution without cryptographic protection a serious
attack vector? attack vector?
skipping to change at page 15, line 39 skipping to change at page 15, line 51
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.
5.5. Per-Hop RLP Flags or Single RLP Flag per Update? 5.5. Per-Hop RLP Flags or Single RLP Flag per Update?
The route-leak detection and mitigation mechanism described in this The route-leak detection and mitigation mechanism described in this
document is based on setting RLP flags on a per-hop basis. There is document is based on setting RLP flags on a per-hop basis. There is
another possible mechanism based on a single RLP flag per update. another possible mechanism based on a single RLP flag per update.
Method A - Per-Hop RLP Flags: The sender on each hop in the AS path Method A - Per-Hop RLP Flags: The sender on each hop in the AS path
sets RLP = 1 if sending the update to a cutomer or lateral peer sets RLP = 1 if sending the update to a customer or lateral peer
(regardless of what the previous ASes in the path set their bits to). (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 No AS (if operating correctly) would rewrite/reset the RLP flags set
by any preceding AS (see Section 3.1). by any preceding AS (see Section 3.1).
Method B - Single RLP Flag per Update: As it propagates, the update Method B - Single RLP Flag per Update: As it propagates, the update
always has only one RLP flag. Once an AS (in the update path) 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 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 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 required that subsequent ASes in the path should always leave the
flag set. flag set.
skipping to change at page 19, line 13 skipping to change at page 19, line 27
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-06 (work in progress), May 2016. definition-06 (work in progress), May 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-15 (work Specification", draft-ietf-sidr-bgpsec-protocol-17 (work
in progress), March 2016. in progress), June 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 20, line 20 skipping to change at page 20, line 30
[Mauch] Mauch, J., "BGP Routing Leak Detection System", Project [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project
web page, 2014, web page, 2014,
<http://puck.nether.net/bgp/leakinfo.cgi/>. <http://puck.nether.net/bgp/leakinfo.cgi/>.
[Mauch-nanog] [Mauch-nanog]
Mauch, J., "Detecting Routing Leaks by Counting", Mauch, J., "Detecting Routing Leaks by Counting",
NANOG-41 Albuquerque, NM, USA, October 2007, NANOG-41 Albuquerque, NM, USA, October 2007,
<https://www.nanog.org/meetings/nanog41/presentations/ <https://www.nanog.org/meetings/nanog41/presentations/
mauch-lightning.pdf>. mauch-lightning.pdf>.
[Nanog-thread-June2016]
"Intra-AS messaging for route leak prevention", NANOG
Email List - Discussion Thread , June 2016,
<http://mailman.nanog.org/pipermail/nanog/2016-June/
thread.html#86348>.
[NIST-800-54] [NIST-800-54]
Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway
Protocol Security", NIST Special Publication 800-54, July Protocol Security", NIST Special Publication 800-54, July
2007, <http://csrc.nist.gov/publications/nistpubs/800-54/ 2007, <http://csrc.nist.gov/publications/nistpubs/800-54/
SP800-54.pdf>. SP800-54.pdf>.
[Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about
How the Internet Works", CloudFare Blog, November 2012, How the Internet Works", CloudFare Blog, November 2012,
<http://blog.cloudflare.com/ <http://blog.cloudflare.com/
why-google-went-offline-today-and-a-bit-about/>. why-google-went-offline-today-and-a-bit-about/>.
skipping to change at page 21, line 5 skipping to change at page 21, line 19
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>. <http://www.rfc-editor.org/info/rfc6811>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>. February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[Snijders]
Snijders, J., "Practical everyday BGP filtering with
AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA,
June 2016, <https://www.nanog.org/sites/default/files/
Snijders_Everyday_Practical_Bgp.pdf>.
[Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. [Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.
Robachevsky , "Methods for Detection and Mitigation of BGP Robachevsky , "Methods for Detection and Mitigation of BGP
Route Leaks", IETF-95 IDR WG Meeting), April 2016, Route Leaks", IETF-95 IDR WG Meeting), April 2016,
<https://www.ietf.org/proceedings/95/slides/slides-95-idr- <https://www.ietf.org/proceedings/95/slides/slides-95-idr-
13.pdf>. 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/>.
 End of changes. 16 change blocks. 
15 lines changed or deleted 38 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/