Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

["Wessels, Duane" <[e-mail]>]

> On Apr 19, 2021, at 4:31 AM, Joe Abley <[e-mail]> wrote:
> 
> 
> Hi Suz,
> 
> On 18 Apr 2021, at 19:17, Suzanne Woolf <[e-mail]> wrote:
> 
>> This message starts the Working Group Last Call for draft-ietf-dnsop-tcp-requirements (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
> 
> I have read draft-ietf-dnsop-dns-tcp-requirements-07 and have the following comments, in flagrant defiance of George's advice to ship the document based mainly on considerations of age. :-)

Thanks Joe!

> 
> I think these are all fairly minor.
> 
> 
> Abstract, Section 4.4 "DNS-over-TLS"
> 
> The abstract includes the sentence "This includes both DNS over unencrpted TCP, as well as over an encrypted TLS session." The later section 4.4 says "this document applies equally well to DNS-over-TLS'.
> 
> The inclusion of DoT looks like an afterthought that has not been entirely afterthought-through. The procedural updates to 1034 in section 3 clearly don't apply to RFC 7858; the justifiable confusion about transports in the DNS (the main topic of this document) also doesn't apply to 7858 which only specifies use of TLS, not DTLS.
> 
> I suggest that this document is really only concerned with strengthening the requirements around the use of TCP transport as described in 1034 and 1035 and that mentioning any other transport is unhelpful and arguably introduces more confusion. I think that sentence should be changed in the abstract to reflect that and section 4.4 should be removed. I would not be surprised to hear that this DoT text was added precisely to address some other earlier reviewer's opinion to the contrary, but this is what I think.

IIRC, DNS-over-TLS was added to this draft following a working group discussion at IETF 104.  I can easily be convinced to remove it, but I would like to hear more people supporting its removal.  I know Tony Finch also already raised questions about including DNS-over-TLS.


> 2.3 EDNS0
> 
> RFC 6891 uses the notation EDNS(0), not EDNS0. Since 6891 obsoletes 2671 it seems reasonable to adopt its notation. I suggest going all search and replace on that.

Okay, done.

> 
> 2.4 Fragmentation and Truncation
> 
> The second paragraph does not mention another fundamental problem with stateless protocols over IPv6 when datagrams require truncation, which is that the requirement in v6 to fragment and resent from the source is not possible when the source has not retained any state regarding to the response that was just sent. While I had my hands in the patient I also added a small reference to tunnel encaps in IPv4.
> 
> OLD:
> 
>    For IPv4-connected hosts, the de-facto MTU is often the Ethernet
>    payload size of 1500 bytes.  This means that the largest unfragmented
>    UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  For
>    IPv6, the situation is a little more complicated.  First, IPv6
>    headers are 40 bytes (versus 20 without options in IPv4).  Second, it
>    seems as though some people have mis-interpreted IPv6's required
>    minimum MTU of 1280 as a required maximum.  Third, fragmentation in
>    IPv6 can only be done by the host originating the datagram.  The need
>    to fragment is conveyed in an ICMPv6 "packet too big" message.  The
>    originating host indicates a fragmented datagram with IPv6 extension
>    headers.  Unfortunately, it is quite common for both ICMPv6 and IPv6
>    extension headers to be blocked by middleboxes.  According to
>    [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to
>    receive a fragmented IPv6 packet.
> 
> NEW:
> 
>    For IPv4-connected hosts, the MTU is often the Ethernet payload
>    size of 1500 bytes.  This means that the largest unfragmented
>    UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
>    although tunnel encapsulation may reduce that maximum message
>    size in some cases.
> 
>    For IPv6, the situation is a little more complicated.  First,
>    IPv6 headers are 40 bytes (versus 20 without options in IPv4).
>    Second, it seems as though some people have mis-interpreted
>    IPv6's required minimum MTU of 1280 as a required maximum.  Third,
>    fragmentation in IPv6 can only be done by the host originating
>    the datagram.  The need to fragment is conveyed in an ICMPv6
>    "packet too big" message.  The originating host indicates a
>    fragmented datagram with IPv6 extension headers.  Unfortunately,
>    it is quite common for both ICMPv6 and IPv6 extension headers
>    to be blocked by middleboxes. According to [HUSTON] some 37% of
>    IPv6-capable recursive resolvers were unable to receive a
>    fragmented IPv6 packet.  Even if the originating host does receive
>    a signal that fragmentation is required, the stateless nature
>    of the DNS protocol is such that the host does not generally
>    retain a copy of the message concerned and hence is unable to  
>    fragment and re-send anyway. 

Thanks, I've added your new text here.

But was the change of Geoff's numbers from 35% to 37% intentional?  I got 35% from this part of the cited article:

    We saw 10,115 individual IPv6 addresses used by IPv6-capable recursive
    resolvers.  Of this set of resolvers, we saw 3,592 resolvers that
    consistently behaved in a manner that was consistent with being unable
    to receive a fragmented IPv6 packet.

Maybe we should meet in the middle (and I should round up) and call it 36%?


> 
> The third paragraph refers to "BIND" without a reference. While it seems ridiculous to imagine that anybody my age would not know what BIND was (ignoring the distinction that has been made between BIND and BIND9) there are other popular products today and terrible young people who are wandering all over my lawn. I think a reference would be useful.

Done.


> 
> The fifth paragraph refers to "growing sentiment in the DNSSEC community" which would benefit from being anchored in time, ideally with a citation.

Cited the 2015 article "Making the Case for Elliptic Curves in DNSSEC" by Rijswijk-Deij et. al.

> 
> 
> 2.5 "Only Zone Transfers Use TCP"
> 
> Second paragraph: replace "historic" ("having importance in or influence on history") with "historical" ("based on past events or set in the past").

Done.

> 
> 
> 4.1 "Connection Establishment and Admission"
> 
> Third paragraph might benefit from a reference to RFC 5358/BCP 140.

Done.

DW