Last Call Review of draft-ietf-grow-route-leak-problem-definition-04

Request Review of draft-ietf-grow-route-leak-problem-definition
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-03
Requested 2016-03-15
Authors Kotikalapudi Sriram, Doug Montgomery, Danny McPherson, Eric Osterweil, Brian Dickson
Draft last updated 2016-04-10
Completed reviews Genart Last Call review of -04 by Pete Resnick (diff)
Genart Telechat review of -04 by Pete Resnick (diff)
Opsdir Last Call review of -04 by Carlos Pignataro (diff)
Rtgdir Early review of -04 by Mach Chen (diff)
Assignment Reviewer Carlos Pignataro
State Completed
Review review-ietf-grow-route-leak-problem-definition-04-opsdir-lc-pignataro-2016-04-10
Reviewed rev. 04 (document currently at 06)
Review result Has Issues
Review completed: 2016-04-10



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


6.  Security Considerations

   No security considerations apply since this is a problem definition

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.


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?


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

   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-

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]

It seems that these final two sentences are not really part of the definition, per se.


   [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.


— Carlos.