Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

"Wessels, Duane" <dwessels@verisign.com> Fri, 27 August 2021 22:44 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 C9BF83A1CEE; Fri, 27 Aug 2021 15:44:09 -0700 (PDT)
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=ham 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 DT9le37Mtnag; Fri, 27 Aug 2021 15:44:04 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.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 0F0043A0B53; Fri, 27 Aug 2021 15:44:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9137; q=dns/txt; s=VRSN; t=1630104245; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=fNXBosEhAs7kvGBHbTjq+QXvoSCLbSN1XjS/avB/9Qg=; b=DAEJuqChXbaqmfWfpSR0TqWTKkRaMIQBigLO6kYxMwhSFTGU+TWZ9TUO 3GkgIADPVFPadGmC+p2k5wBVq0fUfxOqcj7CrpW0EWRHpxvcYAlQNNe1Y nYnACPp3JyxXeuEtll5+YOnt3lRrnZGCC5uN+odPw+PpazzGXbcWPyeq6 HsvGdFKw7XcY/WO/2LhA1bS3lf3y34o7ydRL/RZDXiGHGHe1qZ298P2Bu fpDgqeJfi7cBUc5WiGhWoKmS7LstmASkrD8yw9ceYOytH0J00vAoJ6iTj 0Fz+10D/+A0+wJvIAC4i1UbgjhJ2i8ODJClutdVwizStBXXr7vHUZpWSA g==;
IronPort-SDR: Agkt+djuz32VAYOs8eJ5OR/95+QjHlZX99TMQBcN9ukizVmhzkIDLJdYJSB1llpym1QeKAPv2Q zGjAlOtAp1EcBdTA8AfsZTLDKQIsrQpLccLQ9DdYptZxcIjjToSuoY0PkOayTUdWKz37Zh7cHx GPuBrroeNxqPrJWIFKFfXriTOY7Y/x0dkWq2XAGbmP/wYqH0I4bWjUioB1erdk5Mxv4KYyCoQc kL9rh/XJn+0Ym09iBCDVAFBJ0PIoJnVXOIevqCj/Gan8d/NO/5KbldPrQZD8JZ6u7B6vL4MDK+ d70=
IronPort-HdrOrdr: A9a23:bIlgT6P0uFkc98BcThyjsMiBIKoaSvp037BN7TEVdfU1SL37qy nAppQmPHPP5gr5O0tOpTnoAsDpfZq2z+8X3WB+B9afdTijlmeuIJpr8IfuhxbxcheTysdtkY NtabJ3BtG1L1Rr5PyR3CCIV/It2sOO/qztv/rZ1HsFd2xXQrtt9Bh0ETyWFUBKRA1LbKBTKK ah
X-IronPort-AV: E=Sophos; i="5.84,357,1620691200"; d="p7s'?scan'208"; a="9768606"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 27 Aug 2021 18:44:01 -0400
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.2308.008; Fri, 27 Aug 2021 18:44:01 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org" <draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [EXTERNAL] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Thread-Index: AQHXmckisgvwJIb2nEKLSdGCcMl8yKuIOYkA
Date: Fri, 27 Aug 2021 22:44:00 +0000
Message-ID: <F8DB3441-2D81-4F29-AAB3-D74E24D95453@verisign.com>
References: <162990671395.10583.8870779506155492851@ietfa.amsl.com>
In-Reply-To: <162990671395.10583.8870779506155492851@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.7)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_B6867C73-2759-4B0A-BB2F-A89B01C34EA3"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DxGyHwM889prCBMn1ADTDFevImI>
Subject: Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
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, 27 Aug 2021 22:44:10 -0000


> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <noreply@ietf.org> 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. 
> 
> Reviewer: Mirja Kühlewind
> Review result: Ready with Issues

Hello Mirja,

Thanks for the review.  I haven't had a chance yet to discuss with my
coauthor, John, so these are just my own thoughts at this point.


> 
> 
> First a minor comment here:
> "TCP connection timeout, which is often around 60-120 seconds."
> I guess this value relates to an RTO of 1s and 6 SYN retries which is the
> default in Linux. Maybe say that...? I also recommend to add a link to RFC6298.

Yes suppose it does relate to RTO and SYN retry values, although I'm not
too sure how much those details matter to the intended audience of this
document (DNS software operators).  It says "60-120 seconds" just based
on general experience of how long connection timeouts usually take, without
understanding the inner workings of TCP.

I searched a little for something we could cite to support the 60-120 seconds
statement, but didn't really find anything.  If you think we should use RFC 6298
and the values from Linux to support that, then I guess its fine.

> 
> And a more general comment on section 4.2: this section takes about various
> limits but doesn't recommend any values. I understand that there is not a
> one-fits-all solution here but not knowing how to set these values correctly
> might scared people aways from supporting TCP. So I think having a discussion
> either of default values or how to derives these values based on a certain
> configuration would be a very valuable contribution in this document.

Do you think it would suffice to provide a range of recommended values?
I think we'd have to go back to the working group to get consensus.

Alternatively, are you suggesting to document what defaults are in current
implementations?


> 
> Similarly section 4.3 talks about tuning net.ipv4.tcp_fin_timeout, however, it
> doesn't provide any guidance on how to tune it; Linux recommend a value of
> 15-30 seconds. Also setting net.ipv4.tcp_fin_timeout to a too low value and
> net.ipv4.tcp_tw_reuse to 1 can cause trouble and should not be done for the
> general case. So I don't think that guidance is appropriate without further
> discussion of the risks. Please reconsider this part of the document!


I see your concern.  Would it be okay if we say here that these are for
experts only?  e.g. the sysctl values should only be changed by someone
that has detailed understanding of how TCP works and really understands
the consequences of tweaking them?


> 
> On section 4.4, maybe mention TCP fast open here again as well?
> 

Ack, will do.

DW