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

["Sriram, Kotikalapudi" <[e-mail]>]

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