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? > 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 of the more frequent & pernicious threats to Internet routing security. Weak sauce. > 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 move past that, then how can we have a reasonable discussion on _alternative_ solutions that /are not/ solely in the control plane? > 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 #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? -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
