> 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.
I don't think the conclusion follows from the premises, because it assumes: 1. Specifying new information in the BGP update will have the magical powers of forcing the deployment of said system. 2. The information required to resolve this problem cannot be carried in some other way, nor expressed with something other than a filter --or even that filters cannot express the solution to the leak issue. I find both of these presuppositions to be problematic, at best. > where else does the data from which you make a decision about 'leak or > not' come from? Lots and lots of places. Proposals have been made in the past, only to be shot down because they don't resolve the "man in the middle attack" (which is also a policy failure rather than "attack," and it has nothing to do with "a man in the middle"). Reality check: 1. Leaks are caused, essentially, by someone who isn't following policy. 2. Providers have said (on this list and otherwise) that they are not willing to release _any_ policy in _any_ way, _ever_ into the hands of _anyone_ (even, "this peer is not a transit AS"). 3. Any solution actually adopted _must_ be able to prevent leaks of this type, or it's essentially adding a lot of complexity and overhead for very minimal (or no) gain. Given these three points, we have an impasse. There are three possible solutions to this impasse: 1. Providers realize that much of the policy at the heart of preventing a leak is pretty much already public knowledge (if you're careful in analyzing the BGP table), and hence #2 is a red herring. 2. Create a system that allows you to announce enforceable policy without telling anyone what that policy is. I hear there is research in this area, but I've never seen the problem actually solved. 3. Do nothing. There might be a #4, but I imagine what it is. Russ -- <>< [email protected] [email protected] _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
