Re: [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering
<mohamed.boucadair@orange.com> Fri, 23 November 2018 06:33 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 36B64127333 for <dots@ietfa.amsl.com>; Thu, 22 Nov 2018 22:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 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] 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 we1vpAUWoydv for <dots@ietfa.amsl.com>; Thu, 22 Nov 2018 22:33:43 -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 96EDC1252B7 for <dots@ietf.org>; Thu, 22 Nov 2018 22:33:42 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 431RN43NM8z10HB; Fri, 23 Nov 2018 07:33:40 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 431RN420YqzDq7J; Fri, 23 Nov 2018 07:33:40 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0415.000; Fri, 23 Nov 2018 07:33:39 +0100
From: mohamed.boucadair@orange.com
To: "Panwei (William)" <william.panwei@huawei.com>, kaname nishizuka <kaname@nttv6.jp>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Suggestions about draft-nishizuka-dots-signal-control-filtering
Thread-Index: AdSC2Ej8DSdTqLnvSrCjmhwDCo0iGAAGppVQ
Date: Fri, 23 Nov 2018 06:33:39 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E04C4D0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <30E95A901DB42F44BA42D69DB20DFA6A608D444A@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <30E95A901DB42F44BA42D69DB20DFA6A608D444A@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.168.234.6]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302E04C4D0OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/m1s6_M18bD1w6-lpQh5OBS8lAxc>
Subject: Re: [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering
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, 23 Nov 2018 06:33:46 -0000
Hi Wei, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Panwei (William) Envoyé : vendredi 23 novembre 2018 04:09 À : kaname nishizuka Cc : dots@ietf.org Objet : [Dots] Suggestions about draft-nishizuka-dots-signal-control-filtering Hi Kaname, I have read your draft recently, and I have two suggestions about it. 1. I’d like to suggest using “whitelist” or “DDoS detection whitelist” instead of “accept-list” in the typical case. [Med] accept-list means white-list. accept-list is already used in DOTS requirements and data channel. The signal channel will make use of that term too. FWIW, that change is made because of what was reported by hrpc. A typical case is a DOTS client which configures during peace time filtering rules using data channel to permit traffic from accept- listed sources, but during the volumetric DDoS attack the DDoS mitigator identifies the source addresses/prefixes in the accept- listed filtering rules are attacking the target. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attack traffic or the attacker can compromise the accept- listed sources and program them to launch DDoS attack. In this typical case, when you use “accept-list”, it sounds like that only the traffic which match the accept-list can reach the target. I don’t know if you mean so, but if YES, I feel like the extension may not be essentially needed in such case. Because if a DDoS attack occurs in such situation, the attacker must have been included in the accept-list. The DOTS server can get this conclusion as the DOTS client can, so the DOTS server can de-activate the accept-list by its own without DOTS client’s request of filtering rules. In my opinion, “whitelist” or “DDoS detection whitelist” is more suitable than “accept-list”. Because it indicates that the traffic which doesn’t match the DDoS whitelist can also reach the target, as long as it passes the detection. And if a DDoS attack happens, the DOTS server can’t know if the attacker is in the whitelist. If DOTS client find that the attacker is included in the DDoS whitelist, it must request the DOTS server to de-activate the whitelist. I’m not object to your case, I just want to make it clear and no misunderstanding. 2. I’d like to suggest adding a guideline or suggestion about using signal channel to control filtering rules. The purpose of using DOTS signal channel to control filtering rules is trying to help mitigate the DDoS attack when under attack time. This purpose should also be the guideline. Requests which can help mitigate the attack should be send by the signal channel immediately. Requests which can’t help mitigate the attack should wait for the data channel to be re-established and then be sent by the data channel. For example, during attack time, de-activating a drop-list (or blacklist) or activating a accept-list (or whitelist) may usually not help mitigate the DDoS attack. So If there is no necessary reason, these two requests should wait for using the data channel. [Med] Agree. We do have the following in -01: A DOTS client relies on the information received from the DOTS server and/or local information to the DOTS client domain to trigger a filter control request. Obviously, only filters that are pertinent for an ongoing mitigation should be controlled by a DOTS client using the DOTS signal channel. And The DOTS client can also decide to send a PUT request to deactivate the "an-accept-list" ACL, if suspect traffic is received from an accept-listed source (2001:db8:1234::/48). The structure of that PUT is the same as the one shown in Figure 4. Best Regards Wei Pan 发件人: Dots [mailto:dots-bounces@ietf.org] 代表 kaname nishizuka 发送时间: 2018年11月21日 9:50 收件人: dots@ietf.org 主题: [Dots] Fwd: I-D Action: draft-nishizuka-dots-signal-control-filtering-00.txt Hi, Base on the discussion of Bangkok interop: control data channel filtering via signal channel, we've submitted the new draft for an extension to the DOTS signal channel to control the filtering rules during attack mitigation. thanks, Kaname Nishizuka -------- Forwarded Message -------- Subject: I-D Action: draft-nishizuka-dots-signal-control-filtering-00.txt Date: Tue, 20 Nov 2018 17:42:13 -0800 From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> Reply-To: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Controlling Filtering Rules Using DOTS Signal Channel Authors : Kaname Nishizuka Takahiko Nagata Tirumaleswar Reddy Mohamed Boucadair Filename : draft-nishizuka-dots-signal-control-filtering-00.txt Pages : 11 Date : 2018-11-20 Abstract: This document specifies an extension to the DOTS signal channel to control the filtering rules during attack mitigation. This extension allows a DOTS client to activate or de-activate filtering rules during a DDoS attack. The characterization of these filters is supposed to be conveyed by a DOTS client during peace time by means of DOTS data channel. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Controlling Filtering Rules Using DOTS Signal Channel"; o reference: RFC XXXX o [RFCXXXX] Please update these statements with the RFC number to be assigned to the following documents: o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be [I-D.ietf-dots-signal-channel]) o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification" (used to be [I-D.ietf-dots-data-channel]) Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nishizuka-dots-signal-control-filtering/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-nishizuka-dots-signal-control-filtering-00 https://datatracker.ietf.org/doc/html/draft-nishizuka-dots-signal-control-filtering-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf..org/mailman/listinfo/i-d-announce<https://www.ietf.org/mailman/listinfo/i-d-announce> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
- [Dots] Suggestions about draft-nishizuka-dots-sig… Panwei (William)
- Re: [Dots] Suggestions about draft-nishizuka-dots… mohamed.boucadair
- Re: [Dots] Suggestions about draft-nishizuka-dots… Konda, Tirumaleswar Reddy
- Re: [Dots] Suggestions about draft-nishizuka-dots… Panwei (William)
- Re: [Dots] Suggestions about draft-nishizuka-dots… Jon Shallow
- Re: [Dots] Suggestions about draft-nishizuka-dots… Konda, Tirumaleswar Reddy
- Re: [Dots] Suggestions about draft-nishizuka-dots… mohamed.boucadair
- Re: [Dots] Suggestions about draft-nishizuka-dots… kaname nishizuka
- Re: [Dots] Suggestions about draft-nishizuka-dots… Jon Shallow
- Re: [Dots] Suggestions about draft-nishizuka-dots… Konda, Tirumaleswar Reddy
- Re: [Dots] Suggestions about draft-nishizuka-dots… mohamed.boucadair
- Re: [Dots] Suggestions about draft-nishizuka-dots… Jon Shallow
- Re: [Dots] Suggestions about draft-nishizuka-dots… mohamed.boucadair
- Re: [Dots] Suggestions about draft-nishizuka-dots… Jon Shallow
- Re: [Dots] Suggestions about draft-nishizuka-dots… mohamed.boucadair