> On Dec 7, 2018, at 12:10 AM, Christopher Morrow <[email protected]> > wrote: > > > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <[email protected]> wrote: > > routing area (key agility, a stronger algorithm than MD5). And of course > TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on what > you're referring to here? > > > "TCP-AO is a lie, there is zero deployable code anywhere that supports it" > > was that the gist of his comment? > it'd be the whole of mine... because honestly it's the truth.
I had written out a series of concerns around the requirements operators have.. I can’t find the paper around my office right now I wrote them on, but the went roughly like this: 1) We have long-lived TCP sessions, measured in years. (Implied: many of the transport people really prefer stable routes without flapping/jitter/reordering from us) 2) We use protocols that are stable as a result as transports 3) Security area does review and says “why is MD5 still a thing” without considering #2 and #1 above 4) When doing routing things like an iBGP mesh, key rotation can be complex in a multivendor environment when the catastrophic failure of the network substrate is the consequence of a software bug 5) If these keys (md5) are in use, they’re not rotated because we got that support much later than the ability to set/rotate them and coordination with a network partner to rotate them is feasible but reaches operational impossibility. 6) We need protection from tampering with the transport, not encryption of the transport. You will know where the routes go because I assume you’ve used a tool like traceroute before. There was a longer list. The point of this thread is if you do something “interesting” with your transport, be it IP options, EH, shift your protocol into a space that operators have policed out of necessity (not because we want it), expect broken things to happen. It’s not the early 90s anymore and rolling these things back is much harder than it was. I see daily attacks of hundreds of gigs of UDP against customers, and these won’t make it far because we won’t build network infrastructure to carry them to their destination. We will mitigate the issue, and as always there is collateral damage. If your protocol uses an ephermal port from Gert’s list to connect to a well known port, expect there to be problems. (Look at the history in the early 2000’s why this was built => http://www.zytrax.com/books/dns/ch7/hkpng.html#avoid ) This is not a limited problem to any single protocol, network, device role, etc. It’s not clear to me the IETF is presently equipped to respond to this, but I hope people are listening. - Jared _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
