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

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 21 Sep 2015 11:07:34 +0200

It has been longer than 14 days, apologies for a belated response.

I think that the document is ready to move forward.

My only comment is that it seems that cases 2&3 are sub-cases of 1 and
may also apply to 5,6,7 (i.e. specifics can also be announced in
"lateral" peering). Perhaps it is worth highlighting this fact for
completeness.

Andrei

Christopher Morrow wrote on 10/08/15 19:29:
> 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.
> 
> thanks!
> -chris
> (grow-co-chair)
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Sep 2015 16:46:13 -0400

>   draft-ietf-grow-route-leak-problem-definition

I'm late as usual. :-)

Please consider updating the "replaces-by" for the draft to the original
draft-sriram...

In general, this document is clear and very well written.  It does an
excellent job at summarizing the landscape for route-leaks and provides lots
of citations (which I haven't validated for correctness vs. the issues) for
study.  

The majority of my comments are minor terminology tweaks, some additional
explanations which might or might not be useful content and one discussion
point for re-organizing some of the types.

I'm supportive of this document moving forward even if my comments were not
immediately addressed. 

----

In your section on "type 2", where you use the term "aggregates", consider
normalizing your terminology on "more specific" and "less specific" routes.
While aggregate is semantically clear in this section, aggregation is often
considered in the context of taking multiple more-specific prefixes and
generating a new, less specific prefix.

Type 3 attacks may also be called a "re-origination" attack.  Consider
working that into the text, please.  

One potential source of type 3 attacks may occur when BGP routing
information is redistributed into a non-BGP protocol and then later
taken from that protocol and redistributed.  E.g. BGP->OSPF->BGP.  The
wisdom of ever redistributing BGP into other protocols is left for a
different rant.

Similar to my comment on type 2, Type 4 is treating the matter as a
"de-aggregation" rather than simply announcing internal more specific
routes.  Some of this is perspective, as seen by a receiver, but
understanding the issue is perhaps better done from the perspective of the
originator.

One source of type 4 issues have included how some older vendor implementations
handled its configuration, leading to a trasient announcement of the more
specifics.  A related one may be related to intentional generation of less
specifics from internal more specifics.  In this case, routes contributing
to the aggregate are configured with policy that is intended to suppress
contributing routes, but such policy is only effective after the less
specific aggregate route is created; this creation may lag for various
implementation reasons.

Consider s/prefix-routes/routes/.  The prefix- seems a bit redundant, at
least in a BGP routing context.

Types 5,6 and 7 are effectively forms of type 1.  The only thing varying is
the *context* of the leaked route source AS and destination AS roles.
Perhaps it's worth considering re-grouping the four sections in a way that
highlights that?

-- Jeff