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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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