draft-ietf-idr-route-leak-detection-mitigation-06.txt   draft-ietf-idr-route-leak-detection-mitigation-07.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 7, 2017 B. Dickson Expires: March 10, 2018 B. Dickson
K. Patel K. Patel
Arrcus Arrcus
A. Robachevsky A. Robachevsky
Internet Society Internet Society
March 6, 2017 September 6, 2017
Methods for Detection and Mitigation of BGP Route Leaks Methods for Detection and Mitigation of BGP Route Leaks
draft-ietf-idr-route-leak-detection-mitigation-06 draft-ietf-idr-route-leak-detection-mitigation-07
Abstract Abstract
RFC 7908 provides a definition of the route leak problem, and also RFC 7908 provides a definition of the route leak problem, and also
enumerates several types of route leaks. This document first enumerates several types of route leaks. This document first
examines which of those route-leak types are detected and mitigated examines which of those route-leak types are detected and mitigated
by the existing origin validation (OV) [RFC 6811]. It is recognized by the existing origin validation (OV) [RFC 6811]. It is recognized
that OV offers a limited detection and mitigation capability against that OV offers a limited detection and mitigation capability against
route leaks. This document specifies enhancements that significantly route leaks. This document specifies enhancements that significantly
extend the route-leak prevention, detection, and mitigation extend the route-leak prevention, detection, and mitigation
skipping to change at page 1, line 43 skipping to change at page 1, line 43
mitigation of route leaks at ASes downstream from the leaking AS. mitigation of route leaks at ASes downstream from the leaking AS.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2017. This Internet-Draft will expire on March 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 6, line 34 skipping to change at page 6, line 34
detection and mitigation of route leaks of Types 1, 2, 3, and 4 (see detection and mitigation of route leaks of Types 1, 2, 3, and 4 (see
Section 3) at an downstream AS from the leaking AS. Section 3) at an downstream AS from the leaking AS.
4.1. Ascertaining Peering Relationship 4.1. Ascertaining Peering Relationship
There are four possible peering relationships (i.e. roles) an AS can There are four possible peering relationships (i.e. roles) an AS can
have with a neighbor AS: (1) Provider: transit-provider for all have with a neighbor AS: (1) Provider: transit-provider for all
prefixes exchanged, (2) Customer: customer for all prefixes prefixes exchanged, (2) Customer: customer for all prefixes
exchanged, (3) Lateral Peer: lateral peer (i.e. non-transit) for all exchanged, (3) Lateral Peer: lateral peer (i.e. non-transit) for all
prefixes exchanged, and (4) Complex: different relationships for prefixes exchanged, and (4) Complex: different relationships for
different sets of prefixes [I-D.ymbk-idr-bgp-open-policy] [Luckie]. different sets of prefixes [Luckie]. On a per-prefix basis, the
On a per-prefix basis, the peering role types simplify to provider, peering role types simplify to provider, customer, or lateral peer.
customer, or lateral peer.
Operators rely on some form of out-of-band (OOB) (i.e. external to Operators rely on some form of out-of-band (OOB) (i.e. external to
BGP) communication to exchange information about their peering BGP) communication to exchange information about their peering
relationship, AS number, interface IP address, etc. If the relationship, AS number, interface IP address, etc. If the
relationship is complex, the OOB communication also includes the sets relationship is complex, the OOB communication also includes the sets
of prefixes for which they have different roles. of prefixes for which they have different roles.
[I-D.ymbk-idr-bgp-open-policy] introduces a method of confirming the [I-D.ietf-idr-bgp-open-policy] introduces a method of re-confirming
BGP Role during BGP OPEN messaging. It defines a new BGP Role the BGP Role during BGP OPEN messaging (except when the role is
capability, which helps in re-confirming the relationship. BGP Role complex). It defines a new BGP Role capability, which helps in re-
does not replace the OOB communication since it relies on the OOB confirming the relationship when it is provider, customer, or lateral
communication to set the role type in the BGP OPEN message. However, peer. BGP Role does not replace the OOB communication since it
BGP Role provides a means to double check, and if there is a relies on the OOB communication to set the role type in the BGP OPEN
contradiction detected via the BGP Role messages, then a Role message. However, BGP Role provides a means to double check, and if
Mismatch Notification is sent [I-D.ymbk-idr-bgp-open-policy]. there is a contradiction detected via the BGP Role messages, then a
Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy].
When the BGP relationship information has been correctly exchanged When the BGP relationship information has been correctly exchanged
(i.e. free of contradictions) including the sets of prefixes with (i.e. free of contradictions) including the sets of prefixes with
different roles (if complex), then this information SHOULD be used to different roles (if complex), then this information SHOULD be used to
set the role per-prefix with each peer. For example, if the local set the role per-prefix with each peer. For example, if the local
AS's role is Provider with a neighbor AS, then the per-prefix role is AS's role is Provider with a neighbor AS, then the per-prefix role is
set to 'Provider' for all prefixes sent to the neighbor, and set to set to 'Provider' for all prefixes sent to the neighbor, and set to
'Customer' for all prefixes received from the neighbor. 'Customer' for all prefixes received from the neighbor.
4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging 4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging
skipping to change at page 8, line 25 skipping to change at page 8, line 25
A new optional non-transitive BGP Attribute called Preventive Route A new optional non-transitive BGP Attribute called Preventive Route
Leak Protection (pRLP) is used. The attribute type code for the pRLP Leak Protection (pRLP) is used. The attribute type code for the pRLP
attribute is to be assigned by IANA. The length of this attribute is attribute is to be assigned by IANA. The length of this attribute is
0 as it is used only as a flag. 0 as it is used only as a flag.
Ingress (receiving) router action: The decision to set or not set the Ingress (receiving) router action: The decision to set or not set the
pRLP flag is made by a receiving router upon a route ingress. The pRLP flag is made by a receiving router upon a route ingress. The
flag is set when the route is received from a provider or a lateral flag is set when the route is received from a provider or a lateral
peer. The flag is not set when the route is received from a peer. The flag is not set when the route is received from a
customer. When the relationship is complex, the flag is set based on customer. When the relationship is complex, the flag is set based on
the per-prefix peering role information discussed in Section 4.1. the per-prefix peering role information (see Section 4.1).
Egress (sending) router action: A sending router is allowed to send a Egress (sending) router action: A sending router is allowed to send a
route without the pRLP flag to any neighbor (transit-provider, route without the pRLP flag to any neighbor (transit-provider,
customer, lateral peer). However, if the pRLP flag is present, then customer, lateral peer). However, if the pRLP flag is present, then
the route MUST NOT be sent to a transit-provider or a lateral peer. the route MUST NOT be sent to a transit-provider or a lateral peer.
An AS that follows the above set of receiver (ingress) and sender An AS that follows the above set of receiver (ingress) and sender
(egress) actions, prevents itself from causing route leaks. (egress) actions, prevents itself from causing route leaks.
4.3. Route-Leak Protection (RLP) Field Encoding by Sending Router 4.3. Route-Leak Protection (RLP) Field Encoding by Sending Router
skipping to change at page 13, line 21 skipping to change at page 13, line 21
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 [I-D.ietf-idr-aspath-orf] can be helpful (see
discussion in Section 6.4). discussion in Section 6.4).
Another technique based on AS_PATH filters is described in Another technique based on AS_PATH filters is described in
[Snijders]. This method is applicable to very large ISPs (i.e. big [Snijders]. This method is applicable to very large ISPs (i.e. big
networks) that have lateral peering. For a pair of such very large networks) that have lateral peering. For a pair of such very large
ISPs, say A and B, the method depends on ISP A communicating out-of- ISPs, say A and B, the method depends on ISP A communicating out-of-
band (e.g. by email) with ISP B about whether or not it (ISP A) has band (e.g. by email) with ISP B about whether or not it (ISP A) has
any transit providers. This out-of-band knowledge enables ISP B to any transit providers. This out-of-band knowledge enables ISP B to
apply suitable AS_PATH filtering criteria for routes involving the apply suitable AS_PATH filtering criteria for routes involving the
presence of ISP A in the path and prevent certain kinds of route presence of ISP A in the path and prevent certain kinds of route
skipping to change at page 16, line 31 skipping to change at page 16, line 31
adequate to address route leaks. The prefix filtering adequate to address route leaks. The prefix filtering
recommendations in the BCPs may be complementary but not adequate. recommendations in the BCPs may be complementary but not adequate.
The difficulty is in ISPs' ability to construct prefix filters that The difficulty is in ISPs' ability to construct prefix filters that
represent their customer cones (CC) accurately, especially when there represent their customer cones (CC) accurately, especially when there
are many levels in the hierarchy within the CC. In the RLP-encoding are many levels in the hierarchy within the CC. In the RLP-encoding
based solution described here, AS operators signal for each route based solution described here, AS operators signal for each route
propagated, if it SHOULD NOT be subsequently propagated to a transit propagated, if it SHOULD NOT be subsequently propagated to a transit
provider or peer. provider or peer.
AS path based Outbound Route Filter (ORF) described in AS path based Outbound Route Filter (ORF) described in
[draft-ietf-idr-aspath-orf] is also an interesting complementary [I-D.ietf-idr-aspath-orf] is also an interesting complementary
technique. It can be used as an automated collaborative messaging technique. It can be used as an automated collaborative messaging
system (implemented in BGP) for ISPs to try to develop a complete system (implemented in BGP) for ISPs to try to develop a complete
view of the ASes and AS paths in their CCs. Once an ISP has that view of the ASes and AS paths in their CCs. Once an ISP has that
view, then AS path filters can be possibly used to detect route view, then AS path filters can be possibly used to detect route
leaks. One limitation of this technique is that it cannot duly take leaks. One limitation of this technique is that it cannot duly take
into account the fact that routes for prefixes with different peering into account the fact that routes for prefixes with different peering
relationships may be sent over the same link between ASes. Also, the relationships may be sent over the same link between ASes. Also, the
success of AS path based ORF depends on whether ASes at all levels of success of AS path based ORF depends on whether ASes at all levels of
the hierarchy in a CC participate and provide accurate information the hierarchy in a CC participate and provide accurate information
(in the ORF messages) about the AS paths they expect to have in their (in the ORF messages) about the AS paths they expect to have in their
skipping to change at page 19, line 42 skipping to change at page 19, line 42
also thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim also thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim
for their review and comments. for their review and comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
10.2. Informative References 10.2. Informative References
[Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,
and N. Katz-Bassett, "Investigating Interdomain Routing and N. Katz-Bassett, "Investigating Interdomain Routing
Policies in the Wild", ACM Internet Measurement Policies in the Wild", ACM Internet Measurement
Conference (IMC), October 2015, Conference (IMC), October 2015,
<http://www.cs.usc.edu/assets/007/94928.pdf>. <http://www.cs.usc.edu/assets/007/94928.pdf>.
[Cowie2010] [Cowie2010]
skipping to change at page 20, line 20 skipping to change at page 20, line 20
[Cowie2013] [Cowie2013]
Cowie, J., "The New Threat: Targeted Internet Traffic Cowie, J., "The New Threat: Targeted Internet Traffic
Misdirection", Dyn Research/Renesys Blog, November 2013, Misdirection", Dyn Research/Renesys Blog, November 2013,
<http://research.dyn.com/2013/11/ <http://research.dyn.com/2013/11/
mitm-internet-hijacking/>. mitm-internet-hijacking/>.
[draft-dickson-sidr-route-leak-solns] [draft-dickson-sidr-route-leak-solns]
Dickson, B., "Route Leaks -- Proposed Solutions", IETF Dickson, B., "Route Leaks -- Proposed Solutions", IETF
Internet Draft (expired), March 2012, Internet Draft (expired), March 2012,
<https://tools.ietf.org/html/draft-dickson-sidr-route- <https://tools.ietf.org/html/
leak-solns-01>. draft-dickson-sidr-route-leak-solns-01>.
[draft-ietf-idr-aspath-orf]
Patel, K. and S. Hares, "AS path Based Outbound Route
Filter for BGP-4", IETF Internet Draft (expired), August
2007, <https://tools.ietf.org/html/draft-ietf-idr-aspath-
orf-09>.
[draft-kunzinger-idrp-ISO10747-01] [draft-kunzinger-idrp-ISO10747-01]
Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)", Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)",
IETF Internet Draft (expired), November 1994, IETF Internet Draft (expired), November 1994,
<https://tools.ietf.org/pdf/draft-kunzinger-idrp- <https://tools.ietf.org/pdf/
ISO10747-01.pdf>. draft-kunzinger-idrp-ISO10747-01.pdf>.
[Gao] Gao, L. and J. Rexford, "Stable Internet routing without [Gao] Gao, L. and J. Rexford, "Stable Internet routing without
global coordination", IEEE/ACM Transactions on global coordination", IEEE/ACM Transactions on
Networking, December 2001, Networking, December 2001,
<http://www.cs.princeton.edu/~jrex/papers/ <http://www.cs.princeton.edu/~jrex/papers/
sigmetrics00.long.pdf>. sigmetrics00.long.pdf>.
[Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
Interdomain Routing Policies", ACM SIGCOMM Computer Interdomain Routing Policies", ACM SIGCOMM Computer
Communication Review, January 2014, Communication Review, January 2014,
skipping to change at page 21, line 19 skipping to change at page 21, line 9
CTelecom.html>. CTelecom.html>.
[Huston2012] [Huston2012]
Huston, G., "Leaking Routes", March 2012, Huston, G., "Leaking Routes", March 2012,
<http://labs.apnic.net/blabs/?p=139/>. <http://labs.apnic.net/blabs/?p=139/>.
[Huston2014] [Huston2014]
Huston, G., "What's so special about 512?", September Huston, G., "What's so special about 512?", September
2014, <http://labs.apnic.net/blabs/?p=520/>. 2014, <http://labs.apnic.net/blabs/?p=520/>.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-idr-aspath-orf]
Lepinski, M. and K. Sriram, "BGPsec Protocol Hares, S. and K. Patel, "AS Path Based Outbound Route
Specification", draft-ietf-sidr-bgpsec-protocol-22 (work Filter for BGP-4", draft-ietf-idr-aspath-orf-13 (work in
in progress), January 2017. progress), December 2016.
[I-D.ymbk-idr-bgp-open-policy] [I-D.ietf-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Detection and Filtering using Roles in Sriram, "Route Leak Prevention using Roles in Update and
Update and Open messages", draft-ymbk-idr-bgp-open- Open messages", draft-ietf-idr-bgp-open-policy-01 (work in
policy-02 (work in progress), November 2016. progress), July 2017.
[I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-23 (work
in progress), April 2017.
[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,
<https://blog.thousandeyes.com/route-leak-causes-amazon- <https://blog.thousandeyes.com/
and-aws-outage>. 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,
skipping to change at page 23, line 13 skipping to change at page 23, line 8
<https://www.ietf.org/proceedings/06.pdf>. <https://www.ietf.org/proceedings/06.pdf>.
[RFC1105-obsolete] [RFC1105-obsolete]
Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol
(BGP)", IETF RFC (obsolete), June 1989, (BGP)", IETF RFC (obsolete), June 1989,
<https://tools.ietf.org/html/rfc1105>. <https://tools.ietf.org/html/rfc1105>.
[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>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>. February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <http://www.rfc-editor.org/info/rfc7908>. 2016, <https://www.rfc-editor.org/info/rfc7908>.
[Snijders] [Snijders]
Snijders, J., "Practical everyday BGP filtering with Snijders, J., "Practical everyday BGP filtering with
AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA, AS_PATH filters: Peer Locking", NANOG-47 Chicago, IL, USA,
June 2016, <https://www.nanog.org/sites/default/files/ June 2016, <https://www.nanog.org/sites/default/files/
Snijders_Everyday_Practical_Bgp.pdf>. Snijders_Everyday_Practical_Bgp.pdf>.
[Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. [Sriram] Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.
Robachevsky , "Methods for Detection and Mitigation of BGP Robachevsky , "Methods for Detection and Mitigation of BGP
Route Leaks", IETF-95 IDR WG Meeting), April 2016, Route Leaks", IETF-95 IDR WG Meeting), April 2016,
<https://www.ietf.org/proceedings/95/slides/slides-95-idr- <https://www.ietf.org/proceedings/95/slides/
13.pdf>. 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]
Toonk, A., "Massive route leak causes Internet slowdown", Toonk, A., "Massive route leak causes Internet slowdown",
June 2015, <http://www.bgpmon.net/ June 2015, <http://www.bgpmon.net/
massive-route-leak-cause-internet-slowdown/>. massive-route-leak-cause-internet-slowdown/>.
[Wijchers] [Wijchers]
Wijchers, B. and B. Overeinder, "Quantitative Analysis of Wijchers, B. and B. Overeinder, "Quantitative Analysis of
BGP Route Leaks", RIPE-69, November 2014, BGP Route Leaks", RIPE-69, November 2014,
<https://ripe69.ripe.net/presentations/157-RIPE-69- <https://ripe69.ripe.net/
Routing-WG.pdf>. presentations/157-RIPE-69-Routing-WG.pdf>.
[Zmijewski] [Zmijewski]
Zmijewski, E., "Indonesia Hijacks the World", Dyn Zmijewski, E., "Indonesia Hijacks the World", Dyn
Research/Renesys Blog, April 2014, Research/Renesys Blog, April 2014,
<http://research.dyn.com/2014/04/ <http://research.dyn.com/2014/04/
indonesia-hijacks-world/>. indonesia-hijacks-world/>.
Authors' Addresses Authors' Addresses
Kotikalapudi Sriram Kotikalapudi Sriram
 End of changes. 23 change blocks. 
48 lines changed or deleted 47 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/