IETF Logo Mail Archive

Re: [Dots] Comments on draft-nishizuka-dots-signal-control-filtering-02

<mohamed.boucadair@orange.com> Fri, 25 January 2019 09:08 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 B9E7C12D4EF for <dots@ietfa.amsl.com>; Fri, 25 Jan 2019 01:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5Kx69ejgLSkA for <dots@ietfa.amsl.com>; Fri, 25 Jan 2019 01:08:38 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0743E127133 for <dots@ietf.org>; Fri, 25 Jan 2019 01:08:38 -0800 (PST)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 43mCqm28bgz8tVB; Fri, 25 Jan 2019 10:08:36 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 43mCqm15pYz1xp8; Fri, 25 Jan 2019 10:08:36 +0100 (CET)
Received: from OPEXCAUBM33.corporate.adroot.infra.ftgroup (10.114.13.70) by OPEXCLILM6F.corporate.adroot.infra.ftgroup (10.114.31.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 25 Jan 2019 10:08:35 +0100
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0415.000; Fri, 25 Jan 2019 10:08:35 +0100
From: mohamed.boucadair@orange.com
To: "Panwei (William)" <william.panwei@huawei.com>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Comments on draft-nishizuka-dots-signal-control-filtering-02
Thread-Index: AdS0grzeCrAKNsORT9O+dXHIsB7wowAByw2A
Date: Fri, 25 Jan 2019 09:08:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0D99E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <30E95A901DB42F44BA42D69DB20DFA6A6093C342@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <30E95A901DB42F44BA42D69DB20DFA6A6093C342@nkgeml513-mbx.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA0D99EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Gro5EfUOXMiSqiAHgG7qz2N6hYE>
Subject: Re: [Dots] Comments on draft-nishizuka-dots-signal-control-filtering-02
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: Fri, 25 Jan 2019 09:08:40 -0000

Hi Pan,


(1) What is recommended is to enable asynchronous notif (hence the use of the normative language). I’m hesitating to use the normative language for the second sentence.

(2) No text was included about the DOTS server because we do already have the following in the signal channel:

   If the request is missing a mandatory attribute, does not include
   'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
   parameters, or contains invalid or unknown parameters, the DOTS
                           ^^^^^^^
   server MUST reply with 4.00 (Bad Request).

Can you please elaborate on the security issues you have in mind? Thank you.

Cheers,
Med

De : Panwei (William) [mailto:william.panwei@huawei.com]
Envoyé : vendredi 25 janvier 2019 08:58
À : BOUCADAIR Mohamed TGI/OLN
Cc : dots@ietf.org
Objet : Comments on draft-nishizuka-dots-signal-control-filtering-02


Hi Med,



I have read the latest version and I have 2 comments on it.


It is RECOMMENDED for a DOTS client to subscribe to asynchronous
notifications of the attack mitigation, as detailed in
Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the
polling mechanism in Section 4.4.2.2 of
[I-D.ietf-dots-signal-channel] has to be followed by the DOTS client.



Here you have listed two ways for a DOTS client to follow. Since you used “has to” to indicate that DOTS client must follow the polling mechanism when it doesn’t follow the RECOMMENDED way, would it be better for changing “has to” to “MUST”?




A DOTS client MUST NOT use the filtering control over DOTS signal
channel if no attack (mitigation) is active. By default, ACL-related
operations are achieved using the DOTS data channel
[I-D.ietf-dots-data-channel] when no attack is ongoing.



Though we have given the principle for the DOTS client to follow, but we don’t give a corresponding principle for the DOTS server to check. If the DOTS client is misbehaved and the DOTS server doesn’t check, then new security issues may arise.

Do we want to add some rules and methods for the DOTS server to check, or describe this potential threat in the Security Considerations Chapter?





Best Regards

Wei Pan

v2.29.0 | Report a Bug | By Email | System Status