IETF Logo Mail Archive

Re: [Dots] Hi, authors. 3 comments:

<mohamed.boucadair@orange.com> Tue, 05 March 2019 10:29 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 3255B13106E; Tue, 5 Mar 2019 02:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 KSkDAvaIcYRh; Tue, 5 Mar 2019 02:29:56 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEB81293B1; Tue, 5 Mar 2019 02:29:56 -0800 (PST)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 44DCnZ3V7Mz202b; Tue, 5 Mar 2019 11:29:54 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 44DCnZ2TzgzyQ3; Tue, 5 Mar 2019 11:29:54 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0435.000; Tue, 5 Mar 2019 11:29:54 +0100
From: mohamed.boucadair@orange.com
To: kaname nishizuka <kaname@nttv6.jp>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, "draft-nishizuka-dots-signal-control-filtering.authors@ietf.org" <draft-nishizuka-dots-signal-control-filtering.authors@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Hi, authors. 3 comments:
Thread-Index: AQHU0ymQmd9Jij2iakS1ev3UBCSnzaX80wWA
Date: Tue, 05 Mar 2019 10:29:53 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA287D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <C02846B1344F344EB4FAA6FA7AF481F12C9D756B@dggemm511-mbx.china.huawei.com> <21e92c8d-8df0-576a-db08-3163c74bba59@nttv6.jp>
In-Reply-To: <21e92c8d-8df0-576a-db08-3163c74bba59@nttv6.jp>
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_787AE7BB302AE849A7480A190F8B93302EA287D5OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/WS5HG5TwXcsZ1efKoeLZP5AZWyQ>
Subject: Re: [Dots] Hi, authors. 3 comments:
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: Tue, 05 Mar 2019 10:29:58 -0000

Hi Frank, Kaname,

Please see inline.

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka
Envoyé : mardi 5 mars 2019 09:01
À : Xialiang (Frank, Network Standard & Patent Dept); draft-nishizuka-dots-signal-control-filtering.authors@ietf.org
Cc : dots@ietf.org
Objet : Re: [Dots] Hi, authors. 3 comments:

Hi Frank,

On 2019/03/05 15:26, Xialiang (Frank, Network Standard & Patent Dept) wrote:
Hi authors,
I have 3 general comments as below:

1.       Can you clarify the DOTS server administrative domain a little bit? What is the goal we define it?
We'll clarify it and update the draft.


[Med] This is what is called "DOTS server domain" in DOTS drafts. The notion of "administrative domain" is already used/discussed in the arch I-D.



2.       Will this document open a door to make signal channel to cover the functions of data channel more and more?

[Med] No. We do already have this text:



   A DOTS client MUST NOT use the filtering control over DOTS signal

   channel if no attack (mitigation) is active; such requests MUST be

   discarded by the DOTS server with 4.00 (Bad Request).  By default,

   ACL-related operations are achieved using the DOTS data channel

   [I-D.ietf-dots-data-channel<https://tools.ietf.org/html/draft-nishizuka-dots-signal-control-filtering-04#ref-I-D.ietf-dots-data-channel>] when no attack is ongoing.



The draft focuses only on tweaking the status of **existing** filters.



3.       I can accept the situation of changing the accept-list to the "deactivate" status, but is it a common use case we need to change a deny-list to the "immediate" status?
Regarding with 2 and 3, I can add one usecase to the draft.
When a DOTS client noticed that a system in its domain is being attacked, it will try to ask for help to a DOTS server in its transit provider (or somewhere in upstream networks).
Sometimes it is hard to get any information from the DOTS server if the upstream is saturated by attack traffic.
It is good strategy to enable ACL(set by data-channel) immediately first via signal-channel. Especially if it is rate-limit ACL, it will make a room for further communication over signal-channel.
Then, it will send mitigation request to the DOTS server.
This kind of procedure is really used by manual operation. Combination of ACL-based filtering and mitigation appliance is cost effective.
The proposed draft (signal-control-filtering) enable automation of it.

regards,
Kaname





Thanks!


B.R.
Frank

v2.23.0 | Report a Bug | By Email