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

[Jeffrey Haas <[e-mail]>]

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

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