Re: [apps-discuss] APPS-Dir review of draft-ietf-dnsop-edns-chain-query-05

[Ted Hardie <[e-mail]>]

Howdy,

Some discussion below, mostly snipping things where things are clear.

On Sun, Jan 10, 2016 at 9:11 PM, Paul Wouters <[e-mail]> wrote:

> On 11/23/2015 03:24 PM, Ted Hardie wrote:
>
> (added CC: to dnsop list for feedback)
>
> Thanks for your review Ted!
>
> > Major Issues:
> >
> > The effort to avoid amplification attacks is appropriate, but
> justification
> > of the UDP option, even with the EDNS option for a DNS cookie, is not
> well
> > supported in the draft.
>
> I'm a little confused. Do you mean the justification of the COOKIE
> requirement needs more justification, or
> the edns-query-chain option itself needs more justification. I would hope
> the latter is clear - it reduces the
> need for either multiple latency bound round trips or many parallel
> queries and their callbacks.
>
>
​Sorry that I wasn't clear enough here.  I'm not asking for a justification
of the COOKIE, I'm wondering how often this will work over UDP.   Since the
basic issue is that response sizes needed for validation ​may be large, and
the cookie will add between 15-40 bytes, it's not clear to me what range of
UDP payload sizes would actually allow you to use this mechanism over UDP.

If I understand your answer correctly, you are saying that the small number
of bytes here doesn't change distribution of responses that fit into UDP
significantly.  ("The additional size of the COOKIE is not really a problem
here. Those would be very few bytes compared to an abusive long chain that
an attacker could be asking for.")  If the working group believes that's
the case, that's fine.  It might be useful to include a bit of text in the
introduction indicating that this is the expectation, but that sort of text
in archival documents is definitely a matter of taste.



> > Is there a
> ​ ​
> reason for limiting partial answers to the top-most hierarchical
> > responses?  If so, could the document include it?
>
> The reason for limiting the answer from the top down is that it enables
> the querying
> client to extend its own chain further down, and send a new query for the
> same data
> with the updated Closest Trust Point further down. This method guarantees
> that the
> DNS client can work its way to the answer.
>
> If the server decides to send other parts of the chain, the client has to
> modify its
> query target in an attempt to get the top part of the chain it did not
> get. And it has
> no guarantee that the next query will give it another useful hunk of the
> chain.
>
> Additionally, assuming the DNS client to DNS server connection is of high
> latency, and
> the DNS server itself has a low latency uplink, it might actually do the
> DNS client a
> disservice giving it part of the chain instead of querying to create the
> full chain. It
> would also be guessing as to whether the full chain is likely to fit or
> not.
>
> To me, such strategies seem overly complicated, and require more code on
> the DNS client
> implementing handling unexpected partial answers. The top down cut-off
> seems much simpler
> to me. But let's ask the working group as well what they think.
>
>
​I think a short statement like "This strategy somewhat limits the
opportunity to
use cached data but results in lower code complexity for clients by
allowing them
to retain a common query target after a partial answer" would cover this and
might be useful.




>
>
> >
> > To resolve this, the client would have to be able to detect when the
> ENDS0
> > option is suppressed by the path, versus not offered by a Recursive
> > Resolver.   Some further text on how this is discerned would be useful;
> > absent a method, I believe the text in 5.3 is sufficient and 6.5 not
> useful
> > beyond the points made in RFC 6891.
>
> How about removing section 6.5, but moving the one sentence in there:
>
>    A fallback strategy similar to that described in [RFC6891] section
>    6.2.2 SHOULD be employed to avoid persistent interference due to non-
>    clean paths.
>
> to the end of section 5.3? Would that resolve your issue?
>
> ​Yes, that seems to work.​



> >
> > Nits:
> >
> > The abstract uses the term "security aware validating Resolver".  This
> use
> > of "security aware" appears to be the term of art used in RFC 4033, but
> > that may not be obvious; perhaps "DNSSEC validating resolver" would be
> more
> > clear for an abstract?
>
> RFC-7719 DNS Terminology marks all of these terms as "have caused
> confusion". I am fine with DNSSEC validating resolver", but I would like to
> punt this question
> to the authors of RFC-7719. I'll ping them offlist if they miss this
> message on the dnsop list.
>
>
​Fair enough; I'm happy to go along with their advice, whatever it may be.​



> > In section 6.3, the document says:
> >
> >    In the event that there is greater demand for Chain Queries than can
> >    be accommodated, DNS servers may stop advertising the CHAIN option in
> >    successive DNS messages.  This allows, for example, clients with
> >    other candidate servers to query to establish new sessions with
> >    different servers in expectation that those servers might still allow
> >    Chain Queries.
> >
> > Given that this would also apply to UDP CHAIN queries, it is not clear
> why
> > this is in the TCP Session Management section.
>
> Correct. How about renaming section 6.3 from "TCP session management" to
> "session management" ?
>
>
​Sounds good.
​


​Thanks for all your work on this,

Ted​