Thanks. > On Nov 28, 2016, at 9:50 PM, Tirumaleswar Reddy (tireddy) <[email protected]> > wrote: > > Thanks, Jouni. Updated draft. > > -Tiru > >> -----Original Message----- >> From: jouni.nospam [mailto:[email protected]] >> Sent: Monday, November 28, 2016 11:12 PM >> To: Tirumaleswar Reddy (tireddy) <[email protected]> >> Cc: [email protected]; [email protected] >> Subject: Re: gen-art review of draft-ietf-dprive-dnsodtls-12 >> >> Hi, >> >> Sorry for being under the radar. See my comments below. >> >> >>> On Nov 18, 2016, at 8:40 AM, Tirumaleswar Reddy (tireddy) >> <[email protected]> wrote: >>> >>>> -----Original Message----- >>>> From: jouni.nospam [mailto:[email protected]] >>>> Sent: Thursday, November 17, 2016 3:33 PM >>>> To: [email protected] >>>> Cc: [email protected] >>>> 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
