Return-Path: 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)" In-Reply-To: Date: Thu, 21 Feb 2019 14:40:02 +0100 Cc: "mohamed.boucadair@orange.com" , "Teague, Nik" , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: "Konda, Tirumaleswar Reddy" 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: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = : >=20 >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> Sent: Thursday, February 21, 2019 5:55 PM >> To: Mirja Kuehlewind (IETF) ; Teague, Nik >> >> Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; = The IESG >> ; draft-ietf-dots-requirements@ietf.org >> Subject: RE: Re: [Dots] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dots- >> requirements-18: (with DISCUSS and COMMENT) >>=20 >> 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. >>=20 >> Re-, >>=20 >> Please see inline. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] Envoy=C3=A9 = : >>> jeudi 21 f=C3=A9vrier 2019 12:42 =C3=80 : 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=C3=BChlewind's Discuss on draft-ietf-dots- >>> requirements-18: (with DISCUSS and COMMENT) >>>=20 >>> Hi, >>>=20 >>> please see below. >>>=20 >>>> Am 21.02.2019 um 12:18 schrieb Teague, Nik : >>>>=20 >>>> Hi, >>>>=20 >>>>=20 >>>> On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF) >>>> >>> wrote: >>>>=20 >>>>>>> 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." >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>=20 >>>>>> [Med] The requirement as worded is OK. >>>>>=20 >>>>> 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 >>>>=20 >>>> The key part here is =E2=80=98packet=E2=80=99 vs =E2=80=98data=E2=80=99= - 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. >>>=20 >>> Yes, packet loss also occurs also with reliable transports and might >>> lead to connection failure. However, I don=E2=80=99t 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? >>=20 >> [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. >=20 > I have modified the text as follows to address the comment: >=20 > 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=E2=80= =99t think there is any kind of acknowledgment mechanism when unreliable = transport is used. There the use of the word =E2=80=9Eretransmit=E2=80=9C = 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.=E2=80=9C ? Mirja >=20 > -Tiru >=20 >>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >=20