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

From: Christopher Morrow <[email-masked]>
Date: Mon, 10 Aug 2015 13:29:41 -0400

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)

---

From: "George, Wes" <[email-masked]>
Date: Mon, 17 Aug 2015 14:45:19 -0400

I've reviewed the latest version, and generally think that it is ready to
proceed once the below comments are addressed. A cross-review from IDR
might also be useful before it goes to IETF LC.

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". 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. 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.
Type 2 - "Update is crafted by the attacker...success of the attack" -
same comment here about attack vs leak vs offending AS

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.

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.

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.

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.

Thanks,

Wes

On 8/10/15, 1:29 PM, "GROW on behalf of Christopher Morrow"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>GROW mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/grow

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: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 18 Aug 2015 12:18:02 +0000

Thank you, Wes.
The comments you've offered are greatly helpful for improving accuracy 
as well as clarity in what is being said. 
I plan to incorporate them in the next revision (v. -03) soon.

Sriram   
________________________________________
From: GROW <[email-masked]> on behalf of George, Wes <[email-masked]>
Sent: Monday, August 17, 2015 2:45 PM
To: Christopher Morrow; [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: "Susan Hares" <[email-masked]>
Date: Tue, 25 Aug 2015 17:06:32 -0400

Siram: 

Do you want me to post this for a cross-review in IDR? 

Sue Hares 

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Sriram, Kotikalapudi
Sent: Tuesday, August 18, 2015 8:18 AM
To: George, Wes; Christopher Morrow; [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)

Thank you, Wes.
The comments you've offered are greatly helpful for improving accuracy as
well as clarity in what is being said. 
I plan to incorporate them in the next revision (v. -03) soon.

Sriram   
________________________________________
From: GROW <[email-masked]> on behalf of George, Wes
<[email-masked]>
Sent: Monday, August 17, 2015 2:45 PM
To: Christopher Morrow; [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)

I've reviewed the latest version, and generally think that it is ready to
proceed once the below comments are addressed. A cross-review from IDR might
also be useful before it goes to IETF LC.

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". 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. 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.
Type 2 - "Update is crafted by the attacker...success of the attack" - same
comment here about attack vs leak vs offending AS

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.

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.

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.

Thanks,

Wes

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 25 Aug 2015 19:36:02 -0400

that seems like a good idea, thanks!

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 26 Aug 2015 13:33:03 +0000

Sue,

Thank you. I welcome the cross-review, assuming GROW WG chairs are OK with it.

Sriram

>From: Susan Hares [mailto:[email-masked]]
>Sent: Tuesday, August 25, 2015 5:07 PM
>To: Sriram, Kotikalapudi <[email-masked]>; 'George, Wes'
><[email-masked]>; 'Christopher Morrow'
><[email-masked]>; [email-masked]; grow-
>[email-masked]; [email-masked]
>Cc: 'John G. Scudder' <[email-masked]>
>Subject: RE: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
>might