On Wed, 07 Oct 2015 13:51:17 -0700, "Christian Huitema" wrote: >... > >There is some uncertainty about TLS/TCP over anycast IP address. It only works >as long as the path to that IP address remains stable. In theory it works, but >there are potential failures when a client is at about the same distance from >two instantiations of the anycast address. In fact, these failures will also >affect DTLS, since there will most probably be two separate contexts at the >two different locations. It would be useful to have a method to find the >unicast address of a server, so connections could be "pinned" to that address. >...
There's been a lot of discussion about the risk of anycast route changes interfering with DNS-over-TLS or DTLS. You make a good point that TLS vs. DTLS BOTH share this potential problem. They both have shared state at the client and server. In fact, ANY protocol that uses a session key (for performance) will have this risk. (And I think people generally rule out public-key crypto without a session key as too computationally costly.) You propose switching from the anycast address to a discovered unicast address, possibly with a new mechanism. There are actually a LOT of reasons connections can fail---the server can reboot, the server process could be restarted, the server could run out of memory and terminate the connection, a load balancer might change, etc. If there's any shared state, clients must have some means of recovering from all possible failures. (The same is true with "good old" UDP--packets can be lost so the DNS resolver must retry.) I suggest that this general retry mechanism can cover anycast route changes as well as all the other failures. A general retry mechanism should work well if anycast route changes are rare. Multiple people have asserted that, but I've been looking for actual data. Matt Levine, Barrett Lyon, and Todd Underwood had a talk at NANOG 37 in 2006 where they looked at CacheNetworks data and claim very low TCP connection failures to their anycast CDN for web traffic.... only 4 connections "broke" out of 683k (slide 19) over 24 hours. There are a lot of caveats. HTTP is not DNS, as operators of an TCP/anycast service they are not uninterested in the answer, more data would be nice, etc. But that number looks to me like it will be as rare or rarer than other failures. Do we really need a new mechanism to recover from this failure? This suggestion assumes the endpoints are notified on route change. TCP *will* allows get notification because the source/dest 5-tuple can never match after route change to a new anycast instance, so you will always get a RST. For DTLS the crypto state cannot match, so things must fail, but it's worth confirming (and perhaps noting in the DNS-over-DTLS i-d) how such an error will be signaled. -John Heidemann _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
