>> I think if we asked telstra why they didn't filter their customer some >> answer like: >> 1) we did, we goofed, oops! >> 2) we don't it's too hard >> 3) filters? what? >> >> I suspect in the case of 1 it's a software problem that needs more >> belts/suspenders >> I suspect in the case of 2 it's a problem that could be shown to be >> simpler with some resource-certification in place >> I suspect 3 is not likely... (or I hope so). >> >> So, even without defining what a leak is, providing a tool to better >> create/verify filtering would be a boon. > > > > Yes, I agree! > > What I'd hate to see is: > > 4) We fully deployed BGPSEC, and RPKI, and upgraded our > infrastructure, and retooled provisioning, operations and processes > to support it all fully, and required our customers and peers to use it, > and even then this still happened - WTF was the point?
I think this is the point: <https://twitter.com/#!/atoonk/status/165245731429564416> > This "leak" thing is a key vulnerability that simply can't be brushed > aside - that's the crux of my frustration with the current effort. You seem to think that there's some extension/modification to BGPSEC that would fix route leaks in addition to the ASPATH issues that BGPSEC addresses right now. Have you written this up anywhere? I would be interested to read it. --Richard
