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

From: "George, Wes" <[email-masked]>
Date: Sun, 1 Nov 2015 13:02:07 +0000

I just went hunting for an instance of this in IETF land, and only found
references related to two hosts talking to one another from behind the
same NAT.
So, I went hunting on the internet, and everywhere I saw an explanation,
it was of the variant "going out the same interface it came in on" and
used U-turn synonymously. I was unable to find a reference to a definition
as I outlined below. That's not necessarily an issue but we may need to
explain the term before we use it so that there is no confusion.

Thanks,

Wes

On 10/31/15, 10:07 PM, "Sriram, Kotikalapudi"
<[email-masked]> wrote:

>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)
>
>On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi"
><[email-masked]> wrote:
>
>
>Sriram, this is significantly improved. One substantial comment that I
>still have with this version:
>
>>>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”.
>
>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.

________________________________

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: David Farmer <[email-masked]>
Date: Sun, 1 Nov 2015 08:38:06 -0600

Thinking about this a bit, I prefer "hairpin turn" over "U-turn".  In my mind a "hairpin turn" is talking about a tight turn in a road and by necessity a tight turn for the traffic on the road, the road itself turns back on itself.  Where as a "U-turn" talks about a tight turn traffic makes on road, usually to reverse direction on the road or where only the traffic is turning back on itself.  Put another way, you can make a "U-turn" on a perfectly strait road, but you can't make a "hairpin turn" on a strait road.

In the Internet we have a different term for a "U-turn", we generally call that a "loopback".  Therefore I think "hairpin turn" is the most appropriate in this case, unless we really mean a "loopback".

Whichever term we use, it should be clearly defined, it should be obvious at this point there is no clear unambiguous common understanding to rely on here.

Thanks.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

> On Nov 1, 2015, at 07:02, George, Wes <[email-masked]> wrote:
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 1 Nov 2015 21:39:59 +0000

Job,
Thanks for your comments. My responses below.

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

There are a few things to note here:
* A route leak can be either accidental or attack (i.e. deliberate).  
(We have said earlier – may be 99% are accidental and 1% deliberate.
see slide 13: https://www.ietf.org/proceedings/93/slides/slides-93-sidr-5.pdf )
* Type 1 (U-Shaped Turn with Full Prefix) can be a deliberate attack as well.
* Type 5 is same as Type 1 except it has a more specific.
In both cases, the update is “propagated” by offending AS with the AS path left intact
(i.e. takes advantage of loop detection).
A hijack (or accidental mis-origination) is different because there the offending AS 
removes the AS path in essence and “re-originates”  (so data path to 
legitimate destination is not preserved in a hijack unlike Type 1 or Type 5). 
* If someone is being deliberate, they may prefer to use Type 5 over Type 1 
because Type (with more specific) is far more effective.

Please let me know if the above clarification helps.
 
>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.

The way I read [Toonk2015-B] is different. It says:
“One explanation for this could be that these are more specific prefixes 
announced by peers of Telekom Malaysia to Telekom Malaysia and 
are normally supposed to stay regional and not visible via transit.”
So the customers of Telekom Malaysia normally announce these more specifics to 
their transit but it is the transit Telekom Malaysia who is responsible
to keep them regional but failed to do so.
Let me know if you feel that is not the correct interpretation of [Toonk2015-B].

Thanks again.

Sriram

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 1 Nov 2015 21:53:33 +0000

>There's seemingly 1 comment set not responded to on-list (job's last),
>but overall support seems positive. 

I have just posted responses to Job's comments.

>I'll ship a document shepherd
>review northbound post-ietf-meeting week.

Thank you.

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

Yes, we can co-ordinate that. Thanks.

Sriram

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 2 Nov 2015 10:39:09 +1100

oh well, since this conversation got re-ingnited..

> I'd classify this type of announcement a "hijack" or "attack", not a

this makes sense to me, this is the equivalent of several well known
instances of someone's 'internap' box leaking outside their span of
control. So, I agree this is a hijack, not a leak... though clearly
the subnets were 'leaked' outside the span of control, the effect is
really a hijack of the remote prefix.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 2 Nov 2015 09:17:35 +0900

> really a hijack of the remote prefix.

hijack is the practical result of the more specific.

intent is of course something else.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 4 Nov 2015 02:49:56 +0000

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

[Chris]
>really a hijack of the remote prefix.

[Joel Jaeggli]
 >intent is of course something else.

Job and I discussed this in person, and as I understand he makes the following 
two important points regarding Type 5 (U-Turn with more specific) and 
why perhaps it should be omitted from the list of route-leak types:

1.   In Type 5, the offending AS receives a less specific and crafts an update 
with a more specific (with AS path intact, Kapela-Pilosov style). 
The update with the more specific basically was never announced by 
a neighbor and was not there in the RIB. So it is a newly crafted update, 
and not a route leak as such.

2.   The other instance of Type 5 was that the update with the more specific 
was there in the RIB but only for regional TE purpose, and was not meant 
to be announced via transit, but it was leaked. In this case, 
the leaked more specific route existed in the RIB, and was not crafted. 
The leak, however, can be thought of as a Type 1 (prefix) leak; 
no need to characterize it as a Type 5 (more specific).

 I am OK with Job’s line of reasoning. Hoping this is agreeable to others 
in the WG as well, I will proceed to update the draft to omit Type 5. 
However, if anyone feels there is some merit/rationale to keep Type 5, please speak up. 
Thanks.

 Sriram