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

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

Thanks.

> On Nov 28, 2016, at 9:50 PM, Tirumaleswar Reddy (tireddy) <[e-mail]> wrote:
> 
> Thanks, Jouni. Updated draft.
> 
> -Tiru
> 
>> -----Original Message-----
>> From: jouni.nospam [mailto:[e-mail]]
>> Sent: Monday, November 28, 2016 11:12 PM
>> To: Tirumaleswar Reddy (tireddy) <[e-mail]>
>> Cc: [e-mail]; [e-mail]
>> 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)
>> <[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
>