On Wed, Nov 7, 2012 at 5:47 PM, Eric Osterweil <[email protected]> wrote: > > On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: > >> (also, your mail client is not wrapping properly) > > How's my client treatin' ya? :-P
just as broke, bug lodged (I hope) for a fix. >> >> 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: > >> how does your browser verify the ssl certificate on your webserver? > > I can take a whack at that: not well? I think DigiNotar helped to illustrate > some > of the dangers here... Just sayin... ;) point wasn't that multiple-uncontrolled/decentralized certificate authorities were a failure. it's a fair point though, which was why 'single root pls' was/is asked for here. >> 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". > > <broken record> > The offer to provide input to the threats and requirements docs is a genuine > attempt to help. For real! :) I have the sneaking suspicion that this > week's... > err, event... cost some people some sleep. I feel like we _should_ be > addressing it, no? > </broken record> don't disagree, haven't disagreed. (I think) I'm not sure how much sleep got lost, or anything else really about it... except that if the route was originated by the origin-asn in the reported CLI output and the path seen wasn't forged, bgpsec/origin-validation wouldn't have helped. nor did filtering on the upstream/customer peerings (clearly)... so folk that want to fall back on 'but de filterz!!' .. are also in failville. >> >> 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? > > I agree that resource certification is a critical component. > >> 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. > > But couldn't we also claim that they won't do any next-gen anything > tomorrow (rpki/bgpsec)? In that sense, wouldn't the above comment > be a bit pedantic statement? maybe? folk have to see a benefit to any of this in order for it to move into production use. if as a first step resource certification work gets me better filtering and/or more people filtering because more reliable filtering is possible, good. eventually though, people will realize that: 1) not everyone is filtering 2) not everyone will filter 3) the only solution left is something in the bgp update :( if there is another '3', let's talk about that. >> 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 ? > > I think I read in Shane's response that the idea that bits should be added to > BGP is false logic. The fact that these bits are not in BGP today, does > not mean they should be put there tomorrow. My 0.02 is that there that's not what I read, but ok. where else does the data from which you make a decision about 'leak or not' come from? > seem to be enough complexities in the policy semantics that the amount > of effort needed to get the minimum level of expressiveness into BGP > could be a non-starter... Just my 0.02... perhaps you could explain more/better this problem. >>> 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) > > I think there's a very complicated replication and fetching hierarchy too. > afaict, > there is a huge amount of evaluation left to do just to illustrate the scaling > properties and systemic dependencies of the substrate that serves these this is less concerning... and it's beside the discussion of leak-or-not. as noted on-list more than one time I'd love to see some scaling and such work done on the certificate repository... that's not today's problem though. > objects of the rpki... Well, we've seen some surprising complexity and > worrisome performance curves in our preliminary evaluations and simulations. > In short, I think the above misses some of the issues. sure, but not the issue about leaks, so another thread and another day. >> 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. > > What are we (as a wg) trying to solve? I.e. shouldn't we be talking about > threats > and requirements? i think we are/were. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
