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

[Paul Wouters <[e-mail]>]

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.

  One major driver for the work is that the total
> response size needed for validation may be large.

You mean the driver for the COOKIE? Because the driver for the option is not related to response size. I'm assuming
that the amount of data the DNS client will receive is about equal. It's only a matter of whether it comes in via one
DNS query, or multiple DNS queries.

  Using DNS cookies will
> add between 15 and 40 bytes (presuming both client and server cookies are
> used), thus further swelling the response.  Some description of when the
> requester/responder's UDP payload size is likely to be sufficient here
> would be a valuable addition.  If the data is not available now, perhaps it
> could be gathered during the course of experimentation? If that data shows
> the intersection of "fits within UDP" and "answers at least a partial
> chain" is small, then reverting this to TCP-only looks sensible.

The amplification is really only a concern when the source IP is not confirmed, and the packet could be a spoofed source ip packet.
Once you have a DNS COOKIE, it is a confirmed client with source IP, so if it is abusive, it can be blacklisted or ratelimited.

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.

> Minor Issues:
> 
> In 5.4, the document currently describes the process of returning a partial
> chain:
> 
>    If a CHAIN answer would be bigger than the Recursive Resolver is
>    willing to serve, it SHOULD send a partial chain starting with the
>    data closest to the top of the chain.  The client MAY re-send the
>    query with an updated Closest Trust Point until it has received the
>    full chain.  The CHAIN response will contain the lowest Closest Trust
>    Point that was included in the CHAIN answer.
> 
> This describes the intersection of one particular resource constraint and
> the operation of this option.  It seems possible, however that a resolver
> might see other resource constraints which might allow it to answer a
> partial chain from something other than the data closest to the top of the
> chain.  Imagine, for example, that it has cached data for some parts of the
> chain but needs to refresh the cache on some other part.  If the cache fill
> operation is taking significant time, it might prefer to send what data it
> has, and fill the cache in anticipation of the follow-up query.  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.


> In section 6.5, the document says:
> 
>    Many paths between DNS clients and Recursive Resolvers suffer from
>    poor hygiene, limiting the free flow of DNS messages that include
>    particular EDNS0 options, or messages that exceed a particular size.
>    A fallback strategy similar to that described in [RFC6891
> <https://tools.ietf.org/html/rfc6891>] section
> <https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-05#section-6.2.2>
>    6.2.2 <https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-05#section-6.2.2>
> SHOULD be employed to avoid persistent interference due to non-
>    clean paths.

That section link is definitely pointing to the wrong document (this draft instead of RFC6891). Fixed.


> This seems to conflict with the advice in 5.3:
> 
>    However, it is RECOMMENDED that Forwarders remember which
>    upstream Recursive Resolvers did not return the option (and
>    additional data) with their response.  The Forwarder SHOULD fallback
>    to regular DNS for subsequent queries to those Recursive Resolvers.
>    It MAY switch to another Recursive Resolver that does support the
>    CHAIN option or try again later to see if the server has become less
>    loaded and is now willing to answer with Query Chains.
> 
> 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?

> 
> 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.

> 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" ?

> In section 6.4, the document says "partian CHAIN up" where it should say
> "partial CHAIN up".

Fixed.

> In section 6.6, this text was quite hard to parse:
> 
> 
>     Changes in network topology between clients and anycast servers may
>    cause disruption to TCP sessions making use of CHAIN more often than
>    with TCP sessions that omit it, since the TCP sessions are expected
>    to be longer-lived.
> 
> Perhaps:
> 
> Since DNS queries using CHAIN may result in longer TCP sessions,
> network topology changes may disrupt them more frequently.

Changed.

Paul