On Nov 9, 2012, at 9:16 PM, Russ White wrote: > > 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").
Actually, some subset of providers allegedly said this. I've not seen any actual catalog of who, but it is certainly NOT everyone. Lots of other folks do this today, via the IRRs, warts et al. You can get "valid origin" capabilities anywhere without touching the protocols at all. > 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. Concur. > 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. Agreed. And given that providers don't even have a system that allows them to automatically configure their customers based on certificated data, well, can't necessarily blame them when these event occur. Proceeding directly to RPKI-enabled BGPSEC and ignoring this problem as acceptable residual would mean you're more concerned about what's routed on the Internet, as opposed to the broader operational security implications. I could understand why governments or RIRs might find utility in that, but given that neither is in the current operational system and now will be, this gives me pause. Especially with the weight of what's being proposed, where "large scale" measurements don't even represent 1% of today's Internet, or consider things like rollover and other soft state that routers would need to process and effectuate reachability upon. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
