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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 21 February 2019 13:40 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 C1969129284; Thu, 21 Feb 2019 05:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m1--r3OngO6G; Thu, 21 Feb 2019 05:40:08 -0800 (PST)
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 44DE41279E6; Thu, 21 Feb 2019 05:40:08 -0800 (PST)
Received: from 200116b82cde9500947f70fc4af24b59.dip.versatel-1u1.de ([2001:16b8:2cde:9500:947f:70fc:4af2:4b59]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwoa3-0002Wb-M0; Thu, 21 Feb 2019 14:40:03 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <BYAPR16MB2790CD35599D350A706FCD62EA7E0@BYAPR16MB2790.namprd16.prod.outlook.com>
Date: Thu, 21 Feb 2019 14:40:02 +0100
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Teague, Nik" <nteague@Verisign.com>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-dots-requirements@ietf.org" <draft-ietf-dots-requirements@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E97DF3BB-6A6E-4137-81D7-F1D23DCAF4EB@kuehlewind.net>
References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> <5CE85A1F-16DC-485C-BA5F-278E0E8CFF3C@Verisign.com> <3089053C-CF9B-491A-ACB0-0BC053C50E88@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA232C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790CD35599D350A706FCD62EA7E0@BYAPR16MB2790.namprd16.prod.outlook.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550756408;24219637;
X-HE-SMSGID: 1gwoa3-0002Wb-M0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/s8mcH6PVGj_y8yWbAqcXM07-cdg>
Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
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: Thu, 21 Feb 2019 13:40:12 -0000

Hi Tiru,

please see below.

> Am 21.02.2019 um 14:03 schrieb Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>:
> 
>> -----Original Message-----
>> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
>> Sent: Thursday, February 21, 2019 5:55 PM
>> To: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>; Teague, Nik
>> <nteague@Verisign.com>
>> Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; The IESG
>> <iesg@ietf.org>; draft-ietf-dots-requirements@ietf.org
>> Subject: RE: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-
>> requirements-18: (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.
>> 
>> Re-,
>> 
>> Please see inline.
>> 
>> Cheers,
>> Med
>> 
>>> -----Message d'origine-----
>>> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] Envoyé :
>>> jeudi 21 février 2019 12:42 À : Teague, Nik Cc : BOUCADAIR Mohamed
>>> TGI/OLN; dots-chairs@ietf.org; frank.xialiang@huawei.com;
>>> dots@ietf.org; The IESG; draft-ietf-dots- requirements@ietf.org Objet
>>> : Re: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-
>>> requirements-18: (with DISCUSS and COMMENT)
>>> 
>>> Hi,
>>> 
>>> please see below.
>>> 
>>>> Am 21.02.2019 um 12:18 schrieb Teague, Nik <nteague@Verisign.com>:
>>>> 
>>>> Hi,
>>>> 
>>>> 
>>>> On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF)
>>>> <ietf@kuehlewind.net>
>>> wrote:
>>>> 
>>>>>>> 3) In SIG-006 you say:
>>>>>>> "      Due to the higher likelihood of packet loss during a DDoS attack,
>>>>>>>   DOTS servers MUST regularly send mitigation status to authorized
>>>>>>>   DOTS clients which have requested and been granted mitigation,
>>>>>>>   regardless of client requests for mitigation status."
>>>>>>> 
>>>>>>> Please note that this is only true if a not-reliable transport is used.
>>> If a
>>>>>>> reliable transport is used, data is received at the application
>>>>>>> level
>>> without
>>>>>>> loss (but maybe some delay) or the connection is terminated (if
>>>>>>> loss is
>>> too
>>>>>>> high to retransmit successfully).
>>>>>>> 
>>>>>> 
>>>>>> [Med] The requirement as worded is OK.
>>>>> 
>>>>> I disagree, because as I said if a reliable transport is used this
>>>>> is not
>>> true. Maybe you can adapt this sentence slightly to clarify that you
>>> probably had a scenario in mind where an unreliable transport is used
>>>> 
>>>> The key part here is ‘packet’ vs ‘data’ - packets will be lost on
>>>> congested
>>> links regardless of data integrity.  This may degrade connection re-
>>> establishment with tcp and cause data loss in an unreliable transport.
>>> 
>>> Yes, packet loss also occurs also with reliable transports and might
>>> lead to connection failure. However, I don’t this how this requirement
>>> is derived from that effect. If I use a reliable transport and my
>>> connection does not fail, I can be sure that the mitigation status
>>> information have been received correctly, so why do I need to re-send
>> frequently then?
>> 
>> [Med] The text you quoted is not about "frequent retransmission" but about
>> sending updates related to the status of a mitigation in progress. The server has
>> to send regular notifications to update the client about the status of a
>> mitigation.
> 
> I have modified the text as follows to address the comment:
> 
> DOTS server MUST regularly send mitigation status updates to authorized DOTS clients which have requested and been granted mitigation. If unreliable transport is used for the signal channel protocol, due to the higher likelihood of packet loss during a DDoS attack, DOTS server MUST regularly retransmit mitigation status.

Thanks! One wording comment, unless I misunderstood something, I don’t think there is any kind of acknowledgment mechanism when unreliable transport is used. There the use of the word „retransmit“ seems irritating here. Do you maybe want to say something like this:

"DOTS server MUST regularly send mitigation status updates to authorized DOTS clients which have requested and been granted mitigation. If unreliable transport is used for the signal channel protocol, due to the higher likelihood of packet loss during a DDoS attack, DOTS server SHOULD send mitigation status updates more frequently.“

?

Mirja



> 
> -Tiru
> 
>> 
>>> 
>>> Mirja
>>> 
>>> 
>>> 
>