Hi, Sorry for being under the radar. See my comments below.
> On Nov 18, 2016, at 8:40 AM, Tirumaleswar Reddy (tireddy) <tire...@cisco.com> > wrote: > >> -----Original Message----- >> From: jouni.nospam [mailto:jouni.nos...@gmail.com] >> Sent: Thursday, November 17, 2016 3:33 PM >> To: gen-art@ietf.org >> Cc: draft-ietf-dprive-dnsodtls....@ietf.org >> Subject: gen-art review of draft-ietf-dprive-dnsodtls-12 >> >> I am the assigned Gen-ART reviewer for this draft. The General Area Review >> Team (Gen-ART) reviews all IETF documents being processed by the IESG for >> the IETF Chair. Please treat these comments just like any other last call >> comments. >> >> For more information, please see the FAQ at >> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Document: draft-ietf-dprive-dnsodtls-12 >> Reviewer: Jouni Korhonen >> Review Date: 2016-11-17 >> IETF LC End Date: 2016-11-16 >> IESG Telechat date: 2016-12-15 >> >> Summary: >> >> The document is ready for publication. >> >> Comments/questions: >> >> o Section 3.1. has “first-come, first-served” port range. What port range >> this >> actually is? Does it refer to ephemeral port range (rfc6335). > > User Ports, range is 1024-49151; assigned based on first come and first > served policy. Ok. Thanks. Could you state that in the document (with a reference)? >> o Section 6 describes a case where an anycasted DTLS packet reaches a DNS >> server >> that does not have an existing security association with the client. A DTLS >> session resumption should initiated as a result. Is it possible that the >> next >> DTLS message again reaches another DNS server without security >> association, which >> would cause a new fatal alert to be returned.. etc?? If this is the case >> there >> should >> be some text pointing at this case. If I am just confused the current text >> is >> fine. > > It's the same problem as DNS-over-TCP (see > https://tools.ietf.org/html/rfc7766#appendix-A), routing changes can disrupt > TCP, DNS-over-TLS and DNS-over-DTLS session. > > Please suggest additional text you would like us to add. Easiest way here would be saying something along the lines: OLD: context from the DNS-over-DTLS handshake. But when the network configuration changes, a DNS-over-DTLS packet can be received by a server that does not have the necessary cryptographic context. To encourage the client to initiate a new DTLS handshake, DNS servers SHOULD generate a DTLS fatal alert message in response to receiving a DTLS packet for which the server does not have any cryptographic context. Upon receipt of an un-authenicated DTLS fatal alert, the NEW: context from the DNS-over-DTLS handshake. But when the network configuration or routing changes, a DNS-over-DTLS packet can be received by a server that does not have the necessary cryptographic context. Clients using DNS-over-DTLS need to always be prepared to re-initiate DTLS handshake and in the worst case this could even happen immediately after re-initiating a new handshake. To encourage the client to initiate a new DTLS handshake, DNS servers SHOULD generate a DTLS fatal alert message in response to receiving a DTLS packet for which the server does not have any cryptographic context. Upon receipt of an un-authenticated DTLS fatal alert, the ... - Jouni > > -Tiru _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
