> On Apr 22, 2015, at 10:15 AM, 🔓Dan Wing <[email protected]> wrote: > > 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.
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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
