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