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

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 13 Oct 2015 03:40:46 +0000

Wes,

>I've reviewed the latest version, and generally think that it is ready to
>proceed once the below comments are addressed. 

Thank you for your comments and support.
Just submitted a version-03 draft in which your suggestions/comments have been incorporated.
Also, please see responses below. 

>There are several areas in Section 3 where you use attack and leak
>interchangeably in a way that adds a bit of confusion. I think it'd be
>better to pick one and stick with it, probably leak rather than attack,
>and only use attack if you are describing something that is almost always
>malicious rather than accidental.
>I.e.
>attack type 1 - "The update basically makes a
>U-turn at the attacker's multi-homed AS.  
>The attack (accidental or deliberate) often succeeds"
>Previously, you say that you refer to the leaking AS as the "offending
>AS". I'd suggest using that here instead of "the attacker's". 

Done. Replaced “attacker” with “offending AS” in all places except where malicious intent involved.  

>Similarly, you've already said that most leaks are unintentional, so it might be
>better to simplify that next sentence by saying "the leak often succeeds"
>and eliminate the parenthetical. 

Done.

>It is also unclear from the text exactly what you mean by U-Turn 
>(it's not going back the way it came, so actually hairpin might be a better term), 
>so a few words to clarify might be useful.

Hairpin seems to have a connotation that the turn is tight/constricted. 
So now I use the phrase “U-shaped turn” instead of “U-turn”. 

>Type 2 - "Update is crafted by the attacker...success of the attack" -
>same comment here about attack vs leak vs offending AS

Done. Changes made in the new version per your suggestion.

>Type 4 - While often the increase in prefixes causes its own problems
>(dramatically increased routing table size, exceeded max prefix limit,
>etc) you may want to add some text to the effect of "these more specifics
>may cause the routes to be preferred over other aggregate announcements,
>thus redirecting traffic from its normal best path" as that makes it
>clearer what the impact of the leak is in this case.

Done. I have added the wording that you have suggested above. 

>Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically
>peering" really add a lot to the explanation. The rest of your text sounds
>more like you're describing a non-transit relationship (typically only
>announce their customer routes to each other), which I think would be an
>easier term to define and more likely to be something readers would be
>familiar with. Either way, the explanation in this section could benefit
>from a good editing pass for clarity.

I have put in a definition of "lateral" and clarified that it means the same as "non-transit". 
I have used both names where relevant, like, "lateral (i.e. non-transit)".   

>Type 6/7- "its provider" - do you mean its transit provider? Otherwise
>it's unclear what distinguishes this from type 5, and again would be
>useful to use transit/non-transit to clarify.

I now use "transit provider" wherever I was using "provider" before. 

>Also, an editorial nit/personal preference: since there are so few
>sections to this document, it might be useful to take each of the subtypes
>and make it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's
>easier to refer to it in text and reviews - subsections can have HTML
>anchors so that you can link right to them, and they show up in the table
>of contents as well.

Good idea. Done. I have also re-ordered the seven subsections (3.1 through 3.7) 
in accordance with a suggestion from Jeff.

Thanks again.
Sriram

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 13 Oct 2015 03:48:19 +0000

Jeff,

Thanks a lot for your comments and support. 
Just submitted a version-03 draft in which your suggestions/comments have been incorporated.
Also, please see responses below. 

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

I think that is a comment for the chairs. 

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

Thank you for the kind compliments.

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

Thank you. Your comments have pretty much all been addressed
in the revised -03 version just submitted.

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

Done. I now use the "more specifics / less specifics" terminology per your suggestion 
(avoided using "aggregates" where ever not relevant). 

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

Done.

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

Done. Changes made in the document accordingly.

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

Thank you for sharing the insight. I understand 
it is not meant for making changes in the document.

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

The substitution has been made in the revised doc.

>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?

I have changed the Types list into Subsections (3.1. through 3.7) 
per Wes's suggestion. And then I reordered/regrouped
those sections (Types) per your suggestion.
Basically, I've put the types you noted above together
(now they are Sections 3.1 through 3.4).
Also, please see the related comment I have 
added in the 1st paragraph in Section 4.

Sriram

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 13 Oct 2015 03:52:29 +0000

Charles, 

Thank you for your suggestions and support.
Just submitted a version-03 draft in which your suggestions have been incorporated.

>Seems like a good document, the only thing I noticed was some of the
>citations have trailing slashes when not needed, leading to 404.
>[Kapela-Pilosov] [Khare] [Mauch-nanog] for me at least.

I have removed the trailing slashes. So the URLs should be good now.
Just fyi – added a new reference -- [Anwar].

Sriram

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 13 Oct 2015 04:02:43 +0000

Andrei,

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

Thank you for your suggestions and support.
In the version-03 draft that was just submitted,
I put in a new paragraph to incorporate your suggestion. 
Please see Section 4, second paragraph.
Please note that the Types are now organized as subsections,
and also reordered. So the Type numbers (#1 through #7) have been shuffled.

Sriram

---

From: "George, Wes" <[email-masked]>
Date: Fri, 30 Oct 2015 14:01:06 +0000

On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi"
<[email-masked]> wrote:

Sriram, this is significantly improved. One substantial comment that I

>So now I use the phrase “U-shaped turn” instead of “U-turn”.

WG] This may be nitpicking, but I don't think that adding "shaped" is
actually much of an improvement. I was thinking of hairpin from the way
that it is used in VPNs, as in data that enters and leaves the network via
the same edge device, but typically on a different physical or logical
interface (instead of entering on one PE and leaving via another), rather
than the way that it is used on racetracks to describe a near 180 degree
turn.
Here are a few ideas I had of other ways to refer to this:

-  a "detour leak", in that traffic will be detouring through the leaking
ASN
-  "ASN-in-the-middle leak" - similar to MiTM such that invoking the
concept is useful, but it's necessary to disambiguate the two since the
latter has a specific and well-known meaning
-  "parrotting leak" or "game of telephone leak" in that it is repeating
something it learned elsewhere, but introducing a mistake, not unlike the
grade school game of telephone (if you're up for a reference to The
Simpsons, you could call it a "purple monkey dishwasher leak" but that
would likely require too much explanation ;-) )
-  "[accidental | unintentional] transit leak" since the net result of the
leak is that traffic will transit the leaking AS rather than its normal
path

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Job Snijders <[email-masked]>
Date: Fri, 30 Oct 2015 15:15:20 +0100

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 1 Nov 2015 03:07:34 +0000

Wes,

Thanks, Wes, for taking another look. 
And thanks for laying out some interesting (and entertaining) alternative names 
that  can to used instead of "U-Turn".
Like we discussed in the hallway this morning, it makes sense to use "Hairpin Turn" 
instead of "U-Turn", especially considering "Hairpin Turn" has been used in the VPN context.

Sriram

________________________________________
From: George, Wes <[email-masked]>
Sent: Friday, October 30, 2015 10:01 AM
To: Sriram, Kotikalapudi
Cc: [email-masked]; [email-masked] [email-masked]; [email-masked]
Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)

Thanks,

Wes

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 1 Nov 2015 00:45:39 -0400

There's seemingly 1 comment set not responded to on-list (job's last),
but overall support seems positive. I'll ship a document shepherd
review northbound post-ietf-meeting week.

by then sriram should have an updated revision with comments dealt
with as well I beleive?