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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 03 July 2019 16:41 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 A0C081202B4; Wed, 3 Jul 2019 09:41:26 -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 sIAjtL34Ohra; Wed, 3 Jul 2019 09:41:23 -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 3218B1202C5; Wed, 3 Jul 2019 09:41:23 -0700 (PDT)
Received: from 200116b82468ed00dc125255380fc353.dip.versatel-1u1.de ([2001:16b8:2468:ed00:dc12:5255:380f:c353]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hiiJj-0007Dg-8C; Wed, 03 Jul 2019 18:41:11 +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: <DM5PR16MB170519F8C328B05B9ED61EECEAFB0@DM5PR16MB1705.namprd16.prod.outlook.com>
Date: Wed, 3 Jul 2019 18:41:10 +0200
Cc: Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "draft-ietf-dots-data-channel@ietf.org" <draft-ietf-dots-data-channel@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Benjamin Kaduk <kaduk@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD83F907-35D8-4F44-9DEC-8ABB8E27A6EF@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> <24FFE7CE-B91A-4CF4-BB85-D6108ACE0043@kuehlewind.net> <DM5PR16MB170529399AC19B88B321A35DEAF80@DM5PR16MB1705.namprd16.prod.outlook.com> <642531B0-3E3A-4A5C-BD20-C74AA3698936@kuehlewind.net> <DM5PR16MB170519F8C328B05B9ED61EECEAFB0@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;1562172083;4e340f27;
X-HE-SMSGID: 1hiiJj-0007Dg-8C
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/cqJqCbuL1yGw87yQjR4rE9-K0_k>
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: Wed, 03 Jul 2019 16:41:27 -0000

Hi Tiru, hi Med,

Please see below.

> On 3. Jul 2019, at 10:00, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> 
> Hi Mirja,
> 
> Please see inline 
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
>> Sent: Tuesday, July 2, 2019 9:20 PM
>> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
>> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Roman Danyliw <rdd@cert.org>;;
>> dots@ietf.org; The IESG <iesg@ietf.org>;; dots-chairs@ietf.org;
>> mohamed.boucadair@orange.com; draft-ietf-dots-data-channel@ietf.org
>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
>> channel-28: (with DISCUSS and COMMENT)
>> 
>> This email originated from outside of the organization. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>> 
>> Hi Tiru,
>> 
>> Below...
>> 
>>> On 2. Jul 2019, at 16:22, Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>; wrote:
>>> 
>>>> -----Original Message-----
>>>> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
>>>> Sent: Tuesday, July 2, 2019 7:36 PM
>>>> To: Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>;
>>>> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Roman Danyliw <rdd@cert.org>;;
>>>> dots@ietf.org; The IESG <iesg@ietf.org>;; dots-chairs@ietf.org;
>>>> mohamed.boucadair@orange.com; draft-ietf-dots-data-channel@ietf.org
>>>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
>>>> draft-ietf-dots-data-
>>>> channel-28: (with DISCUSS and COMMENT)
>>>> 
>>>> 
>>>> 
>>>> 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?
>>> 
>>> The frequency of updates to drop-list rules can be few milliseconds.  For
>> example, CAPTCHA and cryptographic puzzles can be used by DOTS client
>> domain to determine whether the IP address is used for legitimate purpose
>> or not, and can configure the drop-list rules.
>>> Further, the specification does not mandate the connection to be
>> persistent, but when needed, the probe mechanism applies.
>> 
>> Then it really seems to me that the document would need to provide further
>> guidance when a persistent connection is useful or when it is recommend to
>> close the connection (and reopen if needed).
> 
> Sure, will add the following text:
> 
>   A DOTS client can either maintain a persistent connection or periodic
>   connections with its DOTS server(s).  If the DOTS client needs to
>   frequently update the drop-list or accept-list filtering rules or
>   aliases, it maintains a persistent connection with the DOTS server.
>   For example, CAPTCHA and cryptographic puzzles can be used by the
>   mitigation service in the DOTS client domain to determine whether the
>   IP address is used for legitimate purpose or not, and the DOTS client
>   can frequently update the drop-list filtering rules.  A persistent
>   connection is also useful if the DOTS client subscribes to event
>   notifications (Section 6.3 of [RFC8040]).
> 
> - Tiru and Med

Thanks!

Two more small comments:

At least to me the term “periodic" is not clear. I guess mean something like short-lived connections, where you have a request, you open a connection, send it, get a reply, and close the connection immediately or after a short idle period. Or is there actually any kind of periodicity in the dots protocol in general? Can you pleas clarify.

Also if a persistent connection is used, I think it would (again) be good to clarify what should be done if the connection fails. I think the right advise in this case, is to not reconnect immediately but only if you have another request to send, right?

Mirja


> 
>> 
>> Mirja
>> 
>> 
>>> 
>>> -Tiru
>>> 
>>>> 
>>>> 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).
>>> 
>