Subject: [dns-privacy] Anycast and TCP-based DPRIVE queries

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 22 Apr 2015 10:15:11 -0700

One issue brought up by Phillip Hallam-Baker during the Dallas meeting was anycast.  With any approach encrypting the query, the server needs the cryptographic context to decrypt the query.  Transferring that cryptographic context from the other anycasted server is difficult at scale, so instead the client needs to establish cryptographic context with the new (current) anycast server.  (With DNS over TLS over TCP, the TCP state would need to be transferred, too.)   When a DNS over TLS over TCP query is sent to a new (anycasted) server, that TCP packet will often -- but not always -- elicit a TCP RST from the server and that TCP RST would cause the DPRIVE client to initiate a new handshake.  However, if the TCP already has synchronized state with that same TCP port and same source IP address, and receives a bogus TCP packet, it will send an empty acknowledgement, https://tools.ietf.org/html/rfc793#page-37,

  "3.  If the connection is in a synchronized state (ESTABLISHED,
   FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
   any unacceptable segment (out of window sequence number or
   unacceptible acknowledgment number) must elicit only an empty
   acknowledgment segment containing the current send-sequence number
   and an acknowledgment indicating the next sequence number expected
   to be received, and the connection remains in the same state."

That empty acknowledgement is received by the DPRIVE client but not reported to the application, so the DPRIVE client would have to time out the query.  I don't know how often we might encounter the synchronized state problem -- its frequency occurrence depends on things like:
 * how often anycast causes a new DNS server to be selected for a particular DPRIVE client
 * how long the TCP connection is kept around on anycasted DNS servers,
 * how frequently an IP address is re-assigned (irrespective of NAT or NAPT)
 * TCP port re-use because of address sharing (such as A+P [RFC6346]) and because of NAPT, especially bulk-port allocation popular on CGNs.

Perhaps this is infrequent enough that the typical ~3 second timeout will be good enough to catch it.

-d

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 22 Apr 2015 22:57:47 +0000

> On Apr 22, 2015, at 10:15 AM, 🔓Dan Wing <[email-masked]> wrote:
> 

Hello Dan,

Anyone deploying TCP anycast service should certainly be aware of these "state" issues, so its good to raise them.

However, in my opinion this perfect storm of conditions you describe (established connection, routing change, same IP, same port) will be so uncommon that it will be lost in the noise of all the other things that can lead to clients retrying their queries.  By other things, I'm thinking of packet loss, funky middleboxes, implementation bugs, crashes, bitflips, and so on.

DW