Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document’s intended status is Informational, and provides a working definition and a categorization of the BGP “route leaks”. The document is well organized and generally easy to follow, although could use some editorial re-writes for readability. Summary: Almost Ready with issues Major: 6. Security Considerations No security considerations apply since this is a problem definition document. I do not think that saying “this is a problem definition document and therefore no security considerations apply” is an appropriate escape. This document has clear Operational and Security implications, which should be better spelled out and covered in some detail. As part of the working definition, the document says “Route leaks can be accidental or malicious, but most often arise from accidental misconfigurations.”. The first part of that sentence speaks to Security issues (i.e., malicious intent, attack vector, attack surface), while the second part speaks to Operational issues (i.e., “misconfiguration” as a root cause and source of this problem.) I believe these both deserve much more than a cursory mention. Specifically, a sub-section should delve into accidental vs. malicious, and an operational considerations section should analyze the misconfiguration statement. Minor: This is not an issue with the document content itself, but rather with its metadata. I recommend the datatracker marks draft-ietf-grow-route-leak-problem-definition as replacing draft-sriram-route-leak-problem-definition to track provenance. 1. Introduction Frequent incidents [Huston2012][Cowie2013][Toonk2015-A][Toonk2015-B][ Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in significant disruptions to Internet routing are commonly called "route leaks". Examination of the details of some of these incidents “Frequent” incidents? How frequent these incidents result in “significant disruptions”? Frequent is not too precise of a qualifier… it’s quite vague. Further, in Section 3, we attempt to enumerate (though not exhaustively) different types of route leaks based on observed events This “non exhaustively” clarification made me pause — are there known categories which are not included? Does that limit the value of the taxonomy? Perhaps it should state why other categories are not included (as it is done in the Summary) 2. Working Definition of Route Leaks […] The above definition is not intended to be all encompassing. Perceptions vary widely about what constitutes a route leak. This sentence also made me pause. If it is not inclusive of the thing being defined, then it is not a definition. Isn’t the idea of defining something to become orthogonal to perceptions? What’s the role of perceptions in a definition? Does this sentence effectively dramatically limits the value of the document? The definition seems to also have something potentially missing: the route leak definition deals strictly with re-advertisement of prefixes, and does not include originating of less specific ones. The latter also somewhat “leaks”, in the sense that it has similar implications. Should it be covered? 3. Classification of Route Leaks Based on Documented Events As illustrated in Figure 1, a common form of route leak occurs when a Is the “propagation of a leak” also a leak in itself? Or not? Is the leak only the source AS that initially ‘leaks’ the prefixes (AS3 in Figure 1) or also downstream propagations which do not follow policy also (AS 2 in Figure 1)? The definition in Section 2 would greatly benefit from clarifying this. Maybe there are two definitions in here. 3.1. Type 1: Hairpin Turn with Full Prefix Description: A multi-homed AS learns a route from one upstream ISP and simply propagates it to another upstream ISP (the turn essentially resembling a hairpin). Neither the prefix nor the AS path in the update is altered. This is similar to a straight forward path-poisoning attack [Kapela-Pilosov], but with full prefix. It should be noted that leaks of this type are often accidental (i.e. not malicious). The update basically makes a hairpin turn at the offending AS's multi-homed AS. The leak often succeeds because the second ISP prefers customer announcement over peer announcement of the same prefix. Data packets would reach the legitimate destination There seem to be some interesting pieces of text in here, which again point to the security implications. First, this is similar to an attack. However, then the text says “It should be noted that leaks of this type are often accidental (i.e. not malicious).” How is this known? Where is it quantified? Why? Can it be the case that is used mostly maliciously in the future? Lastly, it goes on to say “The leak often succeeds because” — does succeed speak to intentionality here? 3.2. Type 2: Lateral ISP-ISP-ISP Leak Mauch [Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other. Does that link speak to these business contracts naming these ISPs? It is somewhat strange to go into such detail of problem definition and taxonomy, without any hint as to implications and potential solutions. Perhaps a pointer to draft-ietf-idr-route-leak-detection-mitigation-02 will help? Similarly, I’m a bit surprised not to see a citation / reference for RFC 4271. 9. Informative References Effectively, all references are pointing to a variety of websites and domains. How stable are these in general? Nits: 3.5. Type 5: Prefix Re-Origination with Data Path to Legitimate Origin The first paragraph seems a bit confusing to follow. I suggest a rewrite for clarity. 5. Summary We hope that this work provides the IETF community a basis for pursuing possible BGP enhancements for route leak detection and mitigation. “Hope” seems like a mistaken operative word here. A nit. The document sometimes says ‘route leaks’, other times “route leaks”, and otherwise route leaks. Normalizing these would avoid potential mis-interpretations of the use of ‘ or “. This document builds on and extends earlier work in the IETF by Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route- leak-reqts]. This seems something for the Acknowledgements, not for the Intro perhaps? 2. Working Definition of Route Leaks […] (For literature related to AS relationships and routing policies, see [Gao] [Luckie] [Gill]. For measurements of valley-free violations in Internet routing, see [Anwar] [Giotsas] [Wijchers].) It seems that these final two sentences are not really part of the definition, per se. References: [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in Internet routing - Analysis based on BGP Community data", IEEE ICC 2012, June 2012. Is there a URL for this reference? (Yes, I know the title can be Googled) I hope these comments are useful. Thanks, — Carlos.