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

[Paul Wouters <[e-mail]>]

On 01/11/2016 02:05 PM, Ted Hardie wrote:

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

Oh I see. I would expect most chains to be only 1-2 segments long, so I think those will
fit in a UDP packet, but I have not yet done any careful calculations of that. Obviously,
this option fits much better with edns-tcp-keepalive based (long lived) connections, but
I think a lot of the time UDP will work fine, even with the COOKIE.

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

That answer was more in reply to amplification abuse, and not so much in response to regular operation.

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

Are there any others that would think this paragraph would be useful to add? I have no objection to it, but also don't really see the need to write this out.

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

Great, done in my draft. (Still waiting on Tim or Joel to tell me if I should wait or push a new version now we are in the middle of the LC)

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

Ok, I have this item pending hearing from some more people.


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

Done on my copy as well. Thanks for the prompt reply!

Paul