On Wed, Nov 7, 2012 at 4:37 PM, Danny McPherson <[email protected]> wrote: > > On Nov 7, 2012, at 3:56 PM, Christopher Morrow wrote: > >> I'm not presupposing, I'm saying that today you CAN do what you want >> with IRR data, some folks do this with varying degrees of >> success/failure. you could improve this with RPKI (or resource >> certification)... you'd still be limited to those folks who do >> filtering to begin with. You might pickup more filterers with 'more >> simpler filteringz', but that's a gamble. > > But forcing BGPSEC/RPKI on everyone is better?
no one is forcing bgpsec on people... this is a market economy, people have to see the benefit and agree to use it. > Ohh, and you still have to solve the IRR-esque problem. > ideally, in my world view, I can wrap my IRR lookup: $ whois -h whois.radb.net -K -i mnt-by 'MAINT-AS15169' | head Warning: RIPE flags used with a traditional server. aut-num: AS15169 route: 208.68.108.0/22 origin: AS11344 and wrap that in some resource certification verification... then output prefix-lists. > And the RPKI/BGPSEC steamroller is squashing low-hanging fruit. > which low-hanging fruit? the 'you can make prefix-lists' one? or ? >> If you want to be closer to a solution, do it in the protocol that >> sends the data around, tag the route with a bit(s) that say: >> "customer" or "provider" or "transit" or "jimmyhat" ... sign that >> bit(s) and let's march on. > > Right, that's the disconnect. > > IF you start with solving this IN BGP, you end up here [sidr]. the work here didn't pre-suppose a solution in bgp itself... but there's not much space outside of bgp if you need to solve the leaking problem. it's fairly apparent that folk just don't deploy prefix filters at-all/reliably/updated/etc. if there's a way not in bgp and without resource-certification (rpki data) to stop leaks it'd be great to talk about that. So far I've not heard an answer, I've heard a lot of mish/mash but no 'how about X?' SIDR has worked on a few things, one of which is RPKI, which is really just 'resource certification'. It's added to that the idea that you could verify the origin of a route you hear, and later that the originator could sign the outgoing route such that folk down the line could say: "Yes, that really did originate from FOO-AS". Later/now it's trying to say that the other portion of the path (other than origin) could be verified so you believe the path as you see it is the path the route followed to get to you. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
