(also, your mail client is not wrapping properly) On Wed, Nov 7, 2012 at 2:15 PM, Shane Amante <[email protected]> wrote: > > On Nov 7, 2012, at 1:48 PM, Christopher Morrow <[email protected]> > wrote: >> On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante <[email protected]> wrote: >>> Chris, >>> >>> On Nov 7, 2012, at 11:11 AM, Christopher Morrow <[email protected]> >>> wrote: >>>> there isn't data in bgp today data which tells you 'this path is a >>>> leak'. Even at the immediately-leaked-to peer there isn't data in the >>>> message that's helpful for this problem. >>> >>> Why isn't the above considered putting the cart in front of the horse? >>> Namely, >>> there is this (seemingly) hard requirement that all information must be >>> self-contained within BGP -- even though the above acknowledges that >>> we CANNOT get this information out from BGP. Shouldn't that suggest there >>> is a pretty fundamental problem here wrt the current definition of the >>> problem? >> >> I think if you have only a bgp message to deal with that's all you >> have to base your judgement upon. > > Uhhh ... please tell me how a BGPSEC router, receiving a BGP PDU from another > AS, is supposed to validate a BGPSEC path signature without relying on *any* > offboard systems whatsoever? >
how does your browser verify the ssl certificate on your webserver? > >> The SIDR work so far has added a >> signature for origination and in BGPSEC proposes adding signatures as >> part of bgpsec-path. > > Right, and for all that *additional* complexity & fragility it brings in to > the > global Internet Routing System it still doesn't solve for route leaks ... one if you don't want to do the bgpsec on your network, as an operator you certainly have that choice. If you already filter customer routes (or solve the route-leaks problem in another way) cool, you're probably done? > of the more frequent & pernicious threats to Internet routing security. Weak > sauce. again, propose a solution. I don't think anyone has said 'we do not want to listen to your problem', in fact many people have said: "yes, its a problem, provide a solution". also, resource-certification helps get to a filtering solution of more worth/merit... so that's nice, and isn't more goop on routers or in bgp... so, win? >> If you know of, or can create, or can find inexistence already, data >> that helps solve the 'route leaks problem' please bring it forward. > > The problem with the above is your mandating I present a solution for which, > you yourself, acknowledge no such solution exists. If we cannot accept and have you read brian's 3 drafts, do they help? are they a start to helping? is it off-base? also, I'm not really mandating anything... I'm just chatting. > move past that, then how can we have a reasonable discussion on > _alternative_ solutions that /are not/ solely in the control plane? said several times, added here again: "if you want only to filter routes with the equivalent of prefix-list + irr data, great!" resource certification (rpki) seems like it will help to clean up the filter data better/faster/cleaner than what's in the IRR today. it's not in bgp, it's not in the control-plane... hurray. if you don't think everyone will do filtering tomorrow (we already know they don't today) then we probably should think outside the static filtering realm. >> I >> think the wgs involved here (at least: sidr, idr, grow) all have >> agreed that the first step is: >> 1) show/agree that this is a problem (route leaks) >> 2) see if bgp data already has the right bits to fix this (idr) >> 3) slap some verification on those bits >> >> arguing about carts and horses isn't moving the above 3 steps forward. > > The problem is in step #2, above. Specifically, there's an unwillingness, > which > I don't understand, to accept that "bgp data may not contain the right bits > to fix > this". If we're not willing to admit we have a problem (at step #2), then > step what? isn't that what #2 says? I only outlined the steps forward as agreed upon by the wg and chairs in the affected wgs... maybe I misunderstood your question/point or ? > #3 "slap some verification on those bits" ... is not doing anything to solve > that problem, IMO. > >>> What's even more perplexing is the WG seems to accept that it's OK to >>> accept substantial complexity in creating, exchanging, validating >>> information >>> using an "out-of-band" certificate repository system (RPKI) ... which is OK >>> to >>> be used for Origin Validation by BGP, but for some reason ... BGPSEC is >>> saying that it cannot depend on external information sources for Path >>> Validation (other than per-router/per-AS certs). Something really does not >> >> what external source? > > Doesn't BGPSEC depend on the RPKI for publishing & retrieving of > per-router/per-AS certs? I think techically rpki is just the jumble of certificate data and roas that talk about: o prefixes and ownership (right to use) o as ownerships/right-to-use o origination-information for prefixes/subprefixes (roas) if you just want to 'solve' route-leaks, and you want to do that with filters, you don't need to do anything to bgp. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
