Re: [Gen-art] gen-art review of draft-ietf-dprive-dnsodtls-12

["jouni.nospam" <[e-mail]>]

Hi,

Sorry for being under the radar. See my comments below.


> On Nov 18, 2016, at 8:40 AM, Tirumaleswar Reddy (tireddy) <[e-mail]> wrote:
> 
>> -----Original Message-----
>> From: jouni.nospam [mailto:[e-mail]]
>> Sent: Thursday, November 17, 2016 3:33 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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