Danny said, "Periodic updates of the entire routing table *with much larger and more updates* seems undesirable at best to me, particularly to 'reduce the vulnerability window for replay attacks' to 'days'." --------------------------------------------------------- I think that this is a small part of a much larger issue that has been bugging me since our meeting in Quebec City. After looking at Sriram's estimates around the necessary amount of memory, etc for the different algorithms, I'm bothered by what is being asked of the routing system in support of BGPSec.
For ~5 years, IETF via 4984, & 6227 has said that simply relying on Moore's law to cover the impacts of the growth of the routing table is not sustainable. Yet here we are doing exactly that, while also doing something that will tilt the curve of the memory footprint, processing requirements, etc for the RIB significantly in the wrong direction. When scale comes up, mostly I've heard "well, this isn't going to be deployable for 5 years because you have to ask YFV to build hardware that can support it, but by then it'll be fine, mumble mumble cheap RAM mumble crypto acceleration..." I guess you could say that I'm having a bit of a philosophical crisis over the taste of the Kool-aid here in terms of the benefits vs the potential costs. Don't get me wrong, I very much support SIDR's work and goals, but I think we shouldn't downplay the overall scaling considerations. If it's no longer a concern, or won't be in 5 years, we need to articulate (in a broader forum) the reasons why the concerns and assumptions in 4984/6227 are no longer valid or not applicable to this case. Assuming that the situation hasn't fundamentally changed and those concerns are still valid, the supposed 5-year event horizon for BGPSec adoption makes it somewhat more likely that between now and serious deployment, we will be seriously considering some design changes (whether outputs from RRG or something new) to improve the scalability of the global routing system, and I fear that we will end up with a lovely protocol suite from this WG that would end up in need of radical changes because we've since fundamentally altered the function of the routing system to make it scale better. As far as where this leaves BGPSec, I don't know. Perhaps a solution comes in the form of some of us starting to champion the necessary work to move one or more of the better ideas from RRG into implementation so that the underlying scaling problem is being addressed in parallel. It should be quite possible to incorporate improvements to route security into whatever must already be done to improve scale, and even if not, these are two things that both share a barrier to deployment, especially incrementally, and would certainly benefit from being designed and deployed in concert instead of in separate silos. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
