Last Call Review of draft-ietf-grow-route-leak-problem-definition-04
review-ietf-grow-route-leak-problem-definition-04-opsdir-lc-pignataro-2016-04-10-00

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.