I agree that an attempt at a taxonomy is significant. However I'd keep the leak and hijack separate.
Leak diverts traffic to an unintended path whereas hijack causes DoS or is used for a man-in-the-middle. /Pedro A. Aranda El 26/07/2014 17:21, "Tony Tauber" <[email protected]> escribió: > Well described, Chris. I agree this work is relevant, appropriate and > useful. > > > Tony > > > On Fri, Jul 25, 2014 at 5:23 PM, Christopher Morrow < > [email protected]> wrote: > >> as in the room, I'd hope to focus on-list on: >> "What is a route-leak?" >> >> I thought that a taxonomy: >> "a scheme of classification." >> >> of what route-leaks/hijacks are would be helpful. It's possible that >> we could call all 'hijacks', 'mis-originations', 'valley-free >> violations' the same thing: "Route Leaks"... but having a definition >> and a method to view these from either a direct neighbor OR (ideally) >> 2 as-hops away would be much better. >> >> Sriram/doug's document talks about 4 types of leak, of these 1, 2, 3 >> all basically look the same to me, the original set is: >> 1 - prefix-hijack with path to legitimate origin >> 2 - u-turn with more specific prefix >> 3 - u-turn with full-prefix >> 4 - internal-prefix-leak >> >> To me this sounds like: >> 1, 2, 3 are all saying the same thing: "Someone leaked all or part >> of my prefix, but provided transit to me anyway" >> >> and 4 is mostly lost to me... though I suppose it might mean: "my peer >> leaked my prefix to his transits" >> >> The goal for this work really ought to be: >> define route-leak >> >> Then the next follow-on is: >> "Do operations folks view this thing as defined to be a problem? >> should someone fix that problem?" >> >> -Chris >> >> >> On Fri, Jul 25, 2014 at 3:36 PM, Tony Tauber <[email protected]> wrote: >> > >> > On Fri, Jul 25, 2014 at 3:27 PM, Jared Mauch <[email protected]> >> wrote: >> >> >> >> Communities are not sent by default (eg Cisco). Route leaks come for >> free >> >> on Cisco too. >> > >> > >> > Right, I meant "intentionally implemented" communities. >> > Anyway, so the idea is to introduce a new knob that's on by default and >> > which is more resistant to breaking off? >> > >> > Not so compelling to me as to warrant a wholesale protocol extension. >> > >> > Tony >> > >> >> >> >> On Jul 25, 2014, at 3:12 PM, Tony Tauber <[email protected]> wrote: >> >> >> >> How is this different than tagging with communities today? >> >> In either case, the provider's correct action on the semantics is >> needed >> >> (and can go awry through misconfiguration). >> >> >> >> Tony >> >> >> > >> > >> > _______________________________________________ >> > GROW mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/grow >> > >> > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
