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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 17 July 2019 08:55 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 E3BFE12008C; Wed, 17 Jul 2019 01:55:12 -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 6rxO_R01TPqt; Wed, 17 Jul 2019 01:55:10 -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 2548A1200B6; Wed, 17 Jul 2019 01:55:09 -0700 (PDT)
Received: from 200116b82c292800c8cfb4743a3e4aca.dip.versatel-1u1.de ([2001:16b8:2c29:2800:c8cf:b474:3a3e:4aca]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hnfiH-0004ut-K8; Wed, 17 Jul 2019 10:55:01 +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: <787AE7BB302AE849A7480A190F8B93302EC96FC2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 17 Jul 2019 10:54:58 +0200
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, 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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1A13724-C8D2-4510-9950-156056AF652C@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> <AD83F907-35D8-4F44-9DEC-8ABB8E27A6EF@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB345F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <5C02462E-0067-4A56-940D-15D434676CC6@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EC96FC2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1563353710;bdb03db4;
X-HE-SMSGID: 1hnfiH-0004ut-K8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/fih5hN6rLKXvyvRP7Tx5vuQONSY>
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, 17 Jul 2019 08:55:13 -0000

Hi Med,

Thanks that would be great!

Mirja


> On 17. Jul 2019, at 10:10, <mohamed.boucadair@orange.com>; <mohamed.boucadair@orange.com>; wrote:
> 
> Hi Mirja, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
>> Envoyé : mardi 16 juillet 2019 17:16
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Konda, Tirumaleswar Reddy; Roman Danyliw; dots@ietf.org; Benjamin
>> Kaduk; The IESG; dots-chairs@ietf.org; draft-ietf-dots-data-
>> channel@ietf.org
>> Objet : Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
>> channel-28: (with DISCUSS and COMMENT)
>> 
> [snip]
>>>>> 
>>>>> 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.
>>> 
>>> [Med] We are trying to reuse the same terminology as RESTCONF (draft-
>> ietf-netconf-restconf-client-server).
>>> 
>>> For the DOTS case, the DOTS client is required to register and send
>> requests to refresh the registration in regular intervals (otherwise, the
>> DOTS client won't be able to created filters). Likewise, cycles will be
>> observed because the client will need to maintains the aliases and ACLs it
>> created. The client may use these cycles for any planned activity (create
>> new aliases, create a new filter, etc.) or not.
>>> 
>>>> 
>>>> 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?
>>>> 
>>> 
>>> [Med] draft-ietf-netconf-restconf-client-server voices for the
>> following:
>>> 
>>>  Maintain a persistent connection to the
>>>  RESTCONF server. If the connection goes down,
>>>  immediately start trying to reconnect to the
>>>  RESTCONF server, using the reconnection strategy.
>>> 
>>> Which is the right approach, IMO.
>>> 
>>> We didn't touched on connection management because we are relying on
>> RESTCONF. DOTS will use whatever strategy adopted for RESTCONF.
>>> 
>>> I don't think it is a good idea to add specific behavior into our spec.
>> 
>> That is fine. I wasn’t aware that this is specified like this in RESTCONF
>> and that your are replying on it. Instead of (re-)specifying in this in
>> document, I would recommend to actually add a reference to this part  of
>> the RESTCONF document and make clear that this is what you are replying
>> on.
> 
> [Med] We can cite draft-ietf-netconf-restconf-client-server as an informative reference with the following text:
> 
>   Additional considerations
>   related to RESTCONF connection management (including, configuring the
>   connection type or the reconnect strategy) can be found in
>   [I-D.ietf-netconf-restconf-client-server].
> 
> Better?
> 
>> 
>> Thanks!
>> Mirja