Re: [DNSOP] draft-ietf-dnsop-edns-tcp-keepalive-05

🔓Dan Wing <dwing@cisco.com> Mon, 25 January 2016 22:38 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65851A1B1E for <dnsop@ietfa.amsl.com>; Mon, 25 Jan 2016 14:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.202
X-Spam-Level:
X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ZocQblIGfChK for <dnsop@ietfa.amsl.com>; Mon, 25 Jan 2016 14:38:43 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E011A1B1D for <dnsop@ietf.org>; Mon, 25 Jan 2016 14:38:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2900; q=dns/txt; s=iport; t=1453761523; x=1454971123; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Fo/DpkW5GTLb3b2Sij1Dqxvjqty+wKdZxh+Hcut2ewE=; b=VNSTCjH2TAQc6Ma6ZELgVMCJhV63foO77K0MAGvc//uZXDGitsT5LOWw EbY+buRUgkkZ2BnMpVQlq19jt22zEITI7vPI1muzOWvgVjDu0mN+MVzQI H1o42I0+9LbLyqIID8fhsTK1ddrajymJMy8hMOp0A7dXcaBTNqCbHUlBB A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQBPo6ZW/4QNJK1egzpSbYhXshQBDYFjGAqFbQKBRTgUAQEBAQEBAYEKhEEBAQEDAQEBATc0CxALDgouIQYwBgESiAYDCggOujQNhAIBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYyggSCaYJJgWoWgy6BDwWOHohYhUaGGIF4BokghVOGfYdCHgEBQoIBGIFxGy6HPAEBAQ
X-IronPort-AV: E=Sophos;i="5.22,346,1449532800"; d="scan'208";a="231311143"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2016 22:38:42 +0000
Received: from [10.24.79.172] ([10.24.79.172]) (authenticated bits=0) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0PMcei6008681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2016 22:38:41 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: 🔓Dan Wing <dwing@cisco.com>
In-Reply-To: <56A0FBB2.6000403@gmail.com>
Date: Mon, 25 Jan 2016 14:38:40 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1AA00BE-9B1E-47FC-BB27-D36296DDC60D@cisco.com>
References: <568E8479.9090400@bogus.com> <56A0FBB2.6000403@gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>, joel jaeggli <joelja@bogus.com>
X-Mailer: Apple Mail (2.3112)
X-Authenticated-User: dwing
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/_qWEBnLrFFhfgVOvJWlAQhCMTTI>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, "dnsop-chairs@tools.ietf.org" <dnsop-chairs@tools.ietf.org>
Subject: Re: [DNSOP] draft-ietf-dnsop-edns-tcp-keepalive-05
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 25 Jan 2016 22:38:44 -0000

On 21-Jan-2016 07:39 am, Tim Wicinski <tjw.ietf@gmail.com> wrote:
> 
> DNSOP,
> 
> Joel our AD sent this note out two weeks ago to get some working group consensus on this discussion which came up during the IESG telechat on tcp-keepalive
> 
> I am in agreement with Joel on this (tcp-keepalive is not the mechanism for DTLS), but it should be thought of.
> 
> any opinions? I'd like to get some resolution so we can move this along

The TCP mechanism (edns-tcp-keepalive) negotiates the ability of the client and the server to send multiple DNS queries on the same TCP connection.  As such, it seems ill-named (that is, a title adjustment seems important).  This does not actually "keep the connection alive", which is the traditional meaning of "keepalive" in IETF protocols.  This EDNS0 option is useful for both DNS-over-TCP, as well as DNS-over-TLS-over-TCP.

For DNS-over-DTLS-over-UDP, we should not need to negotiate the client or server capability to send multiple DNS queries over the same DTLS connection; the mere act of negotiating DTLS indicates the ability to handle subsequent DNS queries using that same DTLS connection.  The same might also be true of DNS-over-TLS-over-TCP, in fact?  I mean, is there a client or a server that wants to use DNS-over-TLS-over-TCP and _not_ also have the ability to keep their TCP connection alive for later DNS queries over that same TLS connection?  Perhaps for both DNS-over-TLS, and DNS-over-DTLS, the semantics of edns-tcp-keepalive are implied?

-d







> 
> thanks
> tim
> 
> 
> 
> On 1/7/16 10:30 AM, joel jaeggli wrote:
>> From Stephens discuss, this is a question we should probably answer for
>> ourselves. (it's no longer a consideration as a discuss.
>> 
>>   The question: how does this option play with DNS over
>>   DTLS? [1]
>> 
>>   The reason I ask is that there may be a need in that case
>>   for some similar option (or a TLS extension maybe) though
>>   for the DTLS session lifetime and not a TCP session
>>   lifetime. At present you are saying that this option is
>>   not it. And that's a fine answer but you could also have
>>   said that this could also be used for DTLS session
>>   lifetime handling. And that last might make sense for
>>   operational reasons (not sure really, but could be).
>> 
>>    [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03
>> 
>> My take personally is tcp keepalive option is not the mechanism for
>> dtls, but then we get multiple options specifying essentially the same
>> sort of value at some point in the future.
>> 
>> I just want to make sure we have a good reading on this.
>> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop