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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
