In some ways I think building a taxonomy of scenarios that could be called route-leaks is useful, but I do think there is a danger is overly fixating on a precise definition of a commonly used term (i.e., arguing too much as to what is or is not a route leak).
The real essence of the problem (in my mind) is that the robustness of the global BGP system, as a practical matter makes assumptions about some transitive (3+ AS path) properties of announcements, with out any/enough well know transitive mechanisms in the protocol (other than AS_PATH) to assist in implementing these assumptions, and or detecting that they have been violated. Sending a BGP update to a peer is an implicit authorization to that peer to route traffic from them towards the destination prefix. But the business models of the Internet are such that sending such authorization to a peer is not saying I am willing (or engineered) to route traffic from any and all other networks that my peer might distribute that update too. Often the business model / engineering dictate that the sending AS only intended for that update to be distributed to some subset of the next hops peers. No strictly bi-lateral mechanism will assist a 3rd party to be able to detect that they received an updated that was not the intent of the announcing peer 2+ hops prior. Previous attempts/ideas to completely prescribe solutions to specific problems in this space seem to have failed due to relying on mechanisms that can not be universally prescribed, or on broad access to data sets that have privacy concerns. Our motivation was to think of the problem in this context. Could one add simple mechanism to the protocol that would allow interested parties (both BGP senders and receivers) to indicate some minimal, but useful intended transitive properties of routes, and allow interested receivers to detect in some scenarios that these intended properties have been violated. We chose to look at a set of BGP robustness problems that we could find in the recent literature and trade press. We identified a simple signaling mechanism, not present in the current protocol, that could enable detection/mitigation of all of the scenarios we found in those documents. Solutions to this by definition transitive problem that suggest that everyone just bi-laterally do the right thing, certainly have the problem that they are not robust to single AS, or implementation, failures (implementation or configuration), nor are they robust against a single AS purposefully violating the bi-lateral policy/mechanism. So, another approach to thinking about the problem is to consider if there are common BGP robustness problems that could benefit from a mechanism to tag individual hops along the AS path with additional transitive semantic information. If so, what are those problems, what semantics would tags need to address the problem, and what properties should those tags have (e.g., security, known/wellknown, transitivity, etc). We identified a set of such transitive problems (often called as a "leak" by most) and proposed a simple transitive tagging mechanism that could assist in mitigating them. Other transitive robustness problems maybe addressable with such a mechanism. Those problems may or may not be commonly known as "leaks". Some might identify other scenarios that they might call "leaks" that would not be addressable by such mechanisms. Clearly we need to bound the problem space (in particular, it seems clear that it is not possible to address all bi-lateral policy violations with a simple signaling mechanism) .... an there are some folks who refer to any announcement that violates policy as a leak. dougm 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 > -- DougM at Work
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
