Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

"Wessels, Duane" <dwessels@verisign.com> Fri, 03 December 2021 23:51 UTC

Return-Path: <dwessels@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08403A0BB1; Fri, 3 Dec 2021 15:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJw89rx1bMAs; Fri, 3 Dec 2021 15:51:21 -0800 (PST)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9A33A0BAF; Fri, 3 Dec 2021 15:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6438; q=dns/txt; s=VRSN; t=1638575481; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=1qz/PDOKj8417TgNWlg48eloDofb+Ccutn/9YHll8/o=; b=gYvgrA0b7Z6+yRckJPdSYPphdoYQhm5MT73IBl3tkq7VjkjPwX3VgLfN lzcrCiqA6L4xbJ9Umr2/XRs5x+dtn1nIX2pRmzMnOB5kkl9K6yzSQi7U/ f/2YwXP4o4/TV1UkLsahCFaDg/UpZ0nvSzF7BljeOBpAZf5moyzYQZeSK CPWrdpRt4AYfokLvyp9mIOcin5gAI1LujjlcEw5pnoLM5Jy/yNqFArmSi 2W/GaJW1PKxbxN7ZmDdYOyBbJuSFTtLNntFwQpDRpK2lsflQKEGj4muj1 QNMBrqWXsbhjtekmEdU6OiUpZGVtjHInXq0TtuFX8Aicu+IWJZuTcVdFQ w==;
IronPort-SDR: uDJWXtCRxkF76711zUTgvAyJ/RpLn0qlX1fwzN7gg2Fitbq+Ib6E515+wiFt8+Ld9aZCrrr8Co f3DqM03ytVvsbaKnon0kjrGsxk4rvS6bsRvBPpZD+XyzJKJ9ukKunk1epYure0Xuwksycf0VFg jVQO74yj6T3/ImCYF1+F/sXk6zBSApalIWLOlyQpcBB6bLFhjxs72/XImkrJFlWHh7t/hWRRVJ +7Fg0fftzOGK1GsleMSbzBiAtfCFBriTSuBa7lgbYb2Er+rclfukQH8F54s1a59ZlHrnQp7Q1Y 4ZM=
IronPort-Data: A9a23:oxJcm64TUFBz9uy0ijgO0QxRtOrGchMFZxGqfqrLsTDasY5as4F+v mQdXmCBaP+IamvwLd8iO4yy9klTsJCHyd4yG1A9ryE2Eysa+MHIO4+Ufxz6V8+wwm0vb67GA +E2MISowBUcFyeEzvuV3zuIQUBUjclkfJKlYAL/En03FVAMpBsJ00o5wrdj2tUw27BVPivW0 T/Mi5yHULOa82MsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3fMldG0DFrrx8RYZWc QpjIIaRpQs19z91Yj+suuijLh1SGtY+NyDW4pZdc/DKbhSvOkXee0v0XRYRQR4/ttmHozx+4 OlM9pu6SiImArHFgd06DzxXSHs9HqITrdcrIVDn2SCS52f8VSLT5dheVBtwI4Yf4P4xCG0I6 +YDLnYGaRXra+Cemer9E7Y3wJ1+d4+3bevzuVk5pd3dJfo5TIvYTqHRzcFVxjYrh89IW/3ZY qL1bBI2NU+ZPUMWYz/7Drpjpee1n0jddwFC8kqLpPcm52nYnAJIhe2F3N39P4biqd9utkSRr GbL7kz5BQkRM8GZ1XyO+xqEivDChjj2XJlHSOWm++Rrm1ycwCoYDxg+WV6yu/L/i0OiVZRYM UN80iknobUx3EmqUp/wUwDQiHKetxAAHttdD+N/5AeWzbKR7wCCQ3QPVntbZcU7tdU7QDEsy kShnt71C3poqrL9YX6b7bCMhTK/JSZTKnUNDQcfUBka5MPnrJ4ygh/nQdNqEarzhdrwcRn8x SuNtG01h7wSl9Uj1qin8xbAmT3EjpnEVQEd5wjLUCSi9AwRWWK+T4ay7wHE6/tQdNzcVUeb+ n0FgI2U66YEF5fU0jKXW+NLF7asjxqYDADhbZdUN8FJ31yQF7SLJOi8PBkWyJ9VD/s5
IronPort-HdrOrdr: A9a23:Q95e86DuftpwUULlHelx55DYdb4zR+YMi2TDsHoBLCC9E/bo9f xG88566faZslgssRIb9uxoUZPoKU80nqQFgrX5U43CYCDW/EWlK4145ZbvznnKC0TFmtJ15O NFf7JlANP9SXp3na/BijWQIpIFzMOc+K6lwd3CyWxgJDsGV4h74xxnBh2gHkp6eQlDCfMCf6 ah2g==
X-IronPort-AV: E=Sophos;i="5.87,284,1631592000"; d="scan'208";a="11316611"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.7; Fri, 3 Dec 2021 18:51:19 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2375.007; Fri, 3 Dec 2021 18:51:19 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Joe Abley <jabley@hopcount.ca>
CC: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "draft-ietf-dnsop-dns-tcp-requirements@ietf.org" <draft-ietf-dnsop-dns-tcp-requirements@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Suzanne Woolf <suzworldwide@gmail.com>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Thread-Index: AQHX6KCqd6tZZ+HDhEO4oN8uCkv17w==
Date: Fri, 03 Dec 2021 23:51:19 +0000
Message-ID: <37E6AB92-9F0C-4AFD-84FC-BBFFF129CBCB@verisign.com>
References: <B779A165-3FB3-49F0-B4BD-65AD68E9A933@verisign.com> <FC723F3F-8626-4B96-956B-00C59D384710@hopcount.ca>
In-Reply-To: <FC723F3F-8626-4B96-956B-00C59D384710@hopcount.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3654.120.0.1.13)
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <52DC096B1F04854B8415E0B288250FE8@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kZKXRiPMZXaTcgiAl2FFJhTA-8g>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2021 23:51:26 -0000


> On Nov 8, 2021, at 4:24 PM, Joe Abley <jabley@hopcount.ca> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> On Nov 8, 2021, at 17:35, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org> wrote:
> 
>> Is this better?
>> 
>>  The use of TLS places even stronger operational burdens on DNS
>>  clients and servers.  Cryptographic functions for authentication and
>>  encryption requires additional processing.
> 
> Require, not requires. I know, I know.

Fixed!


> 
>> Unoptimized connection
>>  setup with TLS 1.3 [RFC8446] takes one additional round-trip compared
>>  to TCP.  Connection setup times can be reduced with TCP Fast Open,
>>  and TLS False Start [RFC7918].  TLS session resumption does not
>>  reduce round-trip latency becase no application profile for use of
>>  TLS 0-RTT data with DNS has been published at the time of this
>>  writing.  However, TLS session resumption can reduce the number of
>>  cryptographic operations.
> 
> [...]
> 
>> Agreed, hopefully this is better:
>> 
>>  o  Authoritative servers MUST support and service TCP for receiving
>>     queries, so that resolvers can reliably receive responses that are
>>     larger than what fits in a single UDP packet.
> 
> RFC 6891 anticipates reassembly and doesn't advise against setting a UDP payload size that would cause fragmentation (although it mentions that people should be careful). So "single UDP packet" seems a bit awkward, especially since in principle the size limit is 0xffff octets in both the UDP header and the corresponding EDNS(0) pseudo-header.
> 
> This paragraph (and the ones that follow) seem like they are implying that large responses are the only reason to use TCP (which is surely just a side-effect of wording; I'm not suggesting the authors are unaware of other reasons). Using truncated responses as an example seems fine though.
> 
> I don't think the taxonomy of "authoritative servers", "recursive servers" and "forwarders" is necessarily complete. The terminology in common usage is not tightly bound by common sense, and there is an apparently unlimited supply of words and phrases that people use to mean "a DNS thing attached to a network".
> 
> This seems like it could be a job for "initiators" and "responders", except that in this case I think we're really talking about all DNS implementations, regardless of function. Hooray! Bullet dodged, maybe.
> 
> How about something like:
> 
> o All DNS implementations, regardless of function, MUST support and service TCP for sending and receiving queries, e.g. to accommodate the sending and receiving of DNS messages that are too large to handle using UDP without truncation.

Thanks for pointing this out.  I agree that “single UDP packet” is problematic and we missed this detail before.


Here’s how this text appeared in version 13:

   o  Authoritative servers MUST support and service all TCP queries so
      that they do not limit the size of responses to what fits in a
      single UDP packet.

   o  Recursive servers (or forwarders) MUST support and service all TCP
      queries so that they do not prevent large responses from a TCP-
      capable server from reaching its TCP-capable clients.

Based on Ben’s comments, I then proposed this:

  o  Authoritative servers MUST support and service TCP for receiving
     queries, so that resolvers can reliably receive responses that are
     larger than what fits in a single UDP packet.

  o  Recursive servers (and forwarders) MUST support and service TCP
     for receiving queries, so their TCP-capable clients can reliably
     receive responses that are larger than what fits in a single UDP
     packet.

  o  Recursive servers (and forwarders) MUST support TCP for sending
     queries, so that they can retry truncated UDP responses as
     necessary.


And based on your further suggestions I think it makes sense to combine
authoritative and recursive together, but keep clients as a separate bullet:

   o  DNS servers (including forwarders) MUST support and service TCP
      for receiving queries, so that clients can reliably receive
      responses that are larger than what either side considers too
      large for UDP.

   o  DNS clients MUST support TCP for sending queries, so that they can
      retry truncated UDP responses as necessary.

“what either side considers too large for UDP” is an oblique reference to
EDNS(0) UDP buffer size parameters.

How does that strike you?

DW


> 
> 
> Joe