Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)

[Job Snijders <[e-mail]>]

Hi all,

On Mon, Aug 10, 2015 at 01:29:41PM -0400, Christopher Morrow wrote:
> Howdy grow folk,
> please consider this a WGLC for:
>   draft-ietf-grow-route-leak-problem-definition
> 
> Abstract:
>   "A systemic vulnerability of the Border Gateway Protocol routing
>    system, known as 'route leaks', has received significant attention in
>    recent years.  Frequent incidents that result in significant
>    disruptions to Internet routing are labeled "route leaks", but to
>    date we have lacked a common definition of the term.  In this
>    document, we provide a working definition of route leaks, keeping in
>    mind the real occurrences that have received significant attention.
>    Further, we attempt to enumerate (though not exhaustively) different
>    types of route leaks based on observed events on the Internet.  We
>    aim to provide a taxonomy that covers several forms of route leaks
>    that have been observed and are of concern to Internet user community
>    as well as the network operator community."
> 
> there have been 3 revisions of this document in the WG, along with 2
> prior to adoption. A new read-through of the document and comments
> prior to sending this along to the IESG would be great!
> 
> Let's get that done in the next 14 days and pass this up the chain for
> further review/comment/process.

I think "type 5: U-Shaped Turn with More Specific Prefix" should be
removed from the document.

Given the description:

    "A multi-homed AS learns a route from one upstream ISP and announces
    a subprefix (subsumed in the prefix) to another upstream ISP."

I'd classify this type of announcement a "hijack" or "attack", not a
route leak.

Also, the two mentioned examples are at odds with each other, in the
first example an artificially crafted AS_PATH is used to exploit AS-PATH
loop detection, in the second example, the more specifics observed by
[Toonk2015-B] were more specifics not crafted by the offending ASN but
by peers of the offending ASN for traffic engineering purposes. Those
peers consciously deaggregated, assuming a limited, regionalized
visibility of said prefixes.

Thoughts?

Kind regards,

Job