Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

Mirja Kuehlewind <ietf@kuehlewind.net> Tue, 02 July 2019 14:06 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4898B1200F1; Tue, 2 Jul 2019 07:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 C7e_NbACorTl; Tue, 2 Jul 2019 07:06:31 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6B5120041; Tue, 2 Jul 2019 07:06:31 -0700 (PDT)
Received: from 200116b82c0abb008104c3e4d35e4aa2.dip.versatel-1u1.de ([2001:16b8:2c0a:bb00:8104:c3e4:d35e:4aa2]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hiJQK-0006fk-Km; Tue, 02 Jul 2019 16:06:20 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <DM5PR16MB1705BED0F42996593B0C0A70EAF80@DM5PR16MB1705.namprd16.prod.outlook.com>
Date: Tue, 2 Jul 2019 16:06:19 +0200
Cc: Benjamin Kaduk <kaduk@mit.edu>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-dots-data-channel@ietf.org" <draft-ietf-dots-data-channel@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <24FFE7CE-B91A-4CF4-BB85-D6108ACE0043@kuehlewind.net>
References: <155679628494.24951.9145538661531263463.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68C8B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190701154032.GB13810@kduck.mit.edu> <A4BD2109-EC58-4FED-A8B0-2EE5AC47A69C@kuehlewind.net> <DM5PR16MB1705BED0F42996593B0C0A70EAF80@DM5PR16MB1705.namprd16.prod.outlook.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562076391;c4eb2eb1;
X-HE-SMSGID: 1hiJQK-0006fk-Km
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/t6Gm1d-ikrWoa3Ym9bDCWOsg31A>
Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-data-channel-28=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2019 14:06:34 -0000

Hi Tiru,

Please see below.

> On 2. Jul 2019, at 09:55, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> 
>>>>> I would also quickly like to discuss the use of keep-alives as
>>>>> described in Section 3.1: "While the communication to the DOTS server is
>>>>>  quiescent, the DOTS client MAY probe the server to ensure it has
>>>>>  maintained cryptographic state.  Such probes can also keep alive
>>>>>  firewall and/or NAT bindings.  A TLS heartbeat [RFC6520] verifies
>>>>>  that the DOTS server still has TLS state by returning a TLS message."
>>>>> I understood that multiple requests can and should be send in the
>>>>> same connection, however, I would expect that those requests are
>>>>> send basically right after each other, such as a look-up and then
>>>>> change of the config. I don't see a need to keep up the connection for a
>> long time otherwise.
>>>>> Especially any action performed are (other than in the signal
>>>>> channel case) not time critical. Therefore I would rather recommend
>>>>> to close and reopen connections and not recommend to use keep-alives
>>>>> at all.
>>>> 
>>>> [Med] The activity of the DOTS client may be used to track/detect stale
>> entries:
>>>> 
>>>>  Also, DOTS servers
>>>>  may track the inactivity timeout of DOTS clients to detect stale
>>>>  entries.
>>>> 
>> My understanding is that this is orthogonal. You can also see that a client is
>> inactive when it didn’t open a new connection for a certain time…?
> 
> The drop-list rules could be frequently updated by the DOTS client based on the tests used by the DOTS client domain (e.g. cryptographic challenge) to detect whether the IP address is for legitimate use or not, or based on threat intelligence feeds from security vendors providing the botnet/malicious IP addresses feed.  Further, persistent DOTS data channel is required to handle updates to target resources (e.g. CDN hosting a domain, and it needs DDoS protection) and target IP/prefix may also change frequently (mobile branch office, prefix re-numbering etc.)

This still doesn’t sounds like it is desirable to keep the TCP connection open. Also if you can bear the time to reconnect (1-2 RTT for the handshake) that is usually the better and easier options. I don’t think the information we talk about here are that time-critical, is it? When you say frequent what time frame do you mean, Hours, minutes, seconds, milliseconds?

Mirja


> 
> Further, we are not mandating the connection to be persistent, but when needed, the probe mechanism applies. Please note https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-13 discusses persistent-connection and it’s a client preference on how the connection is maintained (persistent or periodic).