Chris, On Nov 14, 2012, at 10:27 PM, Christopher Morrow <[email protected]> wrote: > Shane, > > See below. > > On Wed, Nov 14, 2012 at 11:33 PM, Shane Amante <[email protected]> wrote: >> Chris, >> >> See below. >> >> On Nov 14, 2012, at 3:18 PM, Christopher Morrow >> <[email protected]> wrote: >> [--snip--] >>> To date there is a draft which discusses route leaks: >>> <http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02> >>> >>> where the authors have attempted to describe one (or many possible) >>> situations which are called 'route leaks'. They also attempt to >>> outline security issues which are follow-on effects of the situation >>> described. >>> >>> SIDR attempted to look at route-leaks and came up a bit stymied, they >>> asked IDR for some assistance with the issue, IDR pushed back to GROW >>> to decide: >>> 1) What is a 'route leak' (perhaps the above draft identifies one >>> examplar to be used in that definition) >> >> See aforementioned draft. It's the most _concise_ definition of the >> problem, as observed repeatedly in the Internet. >> >> >>> 2) Are 'route leaks' a problem that Operations folks care about >> >> Yes! >> >> >>> 3) Should IDR (or the IETF proper) address 'route leaks' with some >>> form(s) of fix action. >> >> WRT "Should IDR" ... that's like Henry Ford asking what color "Model T" I'd >> like, right? Look, no offense to the folks in IDR :-), but as with every >> other WG their present charter is narrowly defined to 'enhancements to BGP'. >> I would hope that _when_the_time_comes_ we remain open-minded about >> conducting a thorough evaluation of the solution space, before deciding to >> further refine one, or more, of those solutions to a standard, or set of >> standards. So, presently, I would not be in favor of exclusively asking IDR >> to fix 'route leaks', given the concerns I've raised above. >> > > apologies, I was a bit rushed in my message (and I note my first > question was poorly chosen, as well) but I had meant to say that the > placement of a solution doesn't have to be in bgp (so doesn't have to > involve IDR), if the WG here takes a look at sees other directions to > go. > >> FWIW, I'm not clear on what you're proposing with "the IETF proper" ... so I >> can't say "yes" to that option either. >> > > 'should the ietf care about this problem, and spend resources > attempting to provide solutions?'
Yes. > is that better? I'm really asking whether or not there is a problem > and if we (ietf in general) can get a solution (or even the > requirements for a solution?) defined... Yes, there is a (big) operational problem wrt route-leaks. Yes, we (IETF in general) should work toward a solution. As I stated previously, I hope we remain open-minded as to the solution space and do not pigeon-hole ourselves into thinking that one must exist inside BGP, either solely or at all. -shane > -chris > >> >>> The end result of the above 3 steps is to push back into IDR one of >>> two action requests: >>> 1) "Yes, route leaks are a problem, please fix them." >>> or >>> 2) "No, route leaks are not a problem, take no action." >>> >>> If #1 above is the answer, and IDR decides that changes to the BGP >>> protocol are warranted (or are a possible solution to the problem) >>> then SIDR has agreed to do what they can to 'secure' the bits >>> added/changed/used in that endeavor. >> >> Dare I ask what happens if IDR decides they do not have an answer? >> >> >>> Could we have some discussion on-list about this problem, and some >>> discussion about whether or not the draft referenced above fits the >>> definition we would like to use for 'route leak'? >> >> Um, yes, but then again I'm a co-author, so clearly you should take this >> answer with a healthy dose of salt. :-) >> >> >>> I would also like >>> the authors of the draft to decide where they would like to take their >>> draft: >>> 1) SIDR >>> 2) IDR >>> 3) GROW >>> 4) other >> >> IMO, since you're asking GROW, the answer should hopefully present itself. >> :-) >> >> -shane > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
