Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-06.txt

Might I suggest the following single additional sentence to section 4?

Where it says: "The DNS server must ensure that the DNS response size does not exceed the Path MTU”

you may want to say:

"The DNS server must ensure that the DNS response size does not exceed the Path MTU, i.e.: Each DTLS record MUST fit within a single datagram, as required by [RFC6347].”

(explicitly reference RFC6347 as the source of this constraint on response sizes)

thanks,
    Geoff

> On 6 Jul 2016, at 11:54 PM, Prashanth Patil (praspati) <praspati@cisco.com> wrote:
> 
> Hi Geoff,
> We¹ve submitted a revision that should address the concern you¹ve rightly
> pointed out below. 
> 
> -Prashanth
> 
> On 5/25/16, 9:24 AM, "dns-privacy on behalf of Geoff Huston"
> <dns-privacy-bounces@ietf.org on behalf of gih@apnic.net> wrote:
> 
>> Hi 
>> 
>> I have been reading this draft and comparing it to the DTLS RFC (RFC6347)
>> 
>> RFC6347 says:
>> 
>> 4.1.1.  Transport Layer Mapping
>> 
>>  Each DTLS record MUST fit within a single datagram.  In order to
>>  avoid IP fragmentation, clients of the DTLS record layer SHOULD
>>  attempt to size records so that they fit within any PMTU estimates
>>  obtained from the record layer.
>> 
>> 
>> 
>> 
>> draft-ietf-dprive-dnsodtls-06.txt says:
>> 
>>  client and server MUST support the EDNS0 option defined in [RFC6891]
>>  so that the DNS client can indicate to the DNS server the maximum DNS
>>  response size it can handle without IP fragmentation.  If the DNS
>>  server's response exceeds the EDNS0 value, the DNS server sets the TC
>>  (truncated) bit.  On receiving a response with the TC bit set, the
>>  client establishes a DNS-over-TLS connection to the same server, and
>>  sends a new DNS request for the same resource record.
>> 
>> These are not precisely consistent. EDNS0 does not specify the maximum
>> unfragmented size, of course. It specifies the maximum size that the
>> querier is willing to reassemble.
>> 
>> To quote from RFC6891
>> 
>>  The requestor's UDP payload size (encoded in the RR CLASS field) is the
>>  number of octets of the largest UDP payload that can be reassembled and
>>  delivered in the requestor's network stack.  Note that path MTU, with
>>  or without fragmentation, could be smaller than this.
>> 
>> So at this point I'm confused. If the intent is to prevent IP
>> fragmentation then the server must sit within the local PMTU estimate, or
>> truncate the response to indicate that it could not do so, which means
>> that the text in the draft needs revision to reflect this normative
>> (MUST) constraint imposed by RFC6347.
>> 
>> Or are these extenuating circumstances in DNS over DTLS that would allow a
>> fragmented response that sits within an offerred EDNS0 UDP Buffer size?
>> If so, then the draft should clearly document what these circumstances are
>> and why the MUST in RFC6347 is not being applied in this case.
>> 
>> thanks,
>> 
>> Geoff
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
> 