Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue

kaname nishizuka <kaname@nttv6.jp> Thu, 25 April 2019 08:59 UTC

Return-Path: <kaname@nttv6.jp>
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 3CB431200E5 for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 01:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttv6.jp
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 7Ff3ux380fBt for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 01:59:35 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 52FBC12006F for <dots@ietf.org>; Thu, 25 Apr 2019 01:59:35 -0700 (PDT)
Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1D39E25F6BF; Thu, 25 Apr 2019 17:59:32 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1556182772; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D+RUJSn5yjyLGHsr7jipGTdB7l5PcbPGC4d1tzou32g=; b=Ut3R8sKOnKJ+ruaRTWKdYOBLS6j6T3+v+9Iq/8C7yA+YelJKMJ+1Ix6wkHQilvcSMnlLZl tifKivLw6G5eUE72ZuFIMt4KK5hiNgX/e9e7rm05XNvKP89hpUGonwALxFjzHvHxyVdvF1 c43XmypZOSHbvpAzZI8+sadu9uYSBIQ=
Received: from macbook-pro-17.lv4.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 0E4EA759005; Thu, 25 Apr 2019 17:59:32 +0900 (JST)
To: mohamed.boucadair@orange.com, "dots@ietf.org" <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: kaname nishizuka <kaname@nttv6.jp>
Message-ID: <c3c9614f-908a-c132-cd35-6c627e341f2b@nttv6.jp>
Date: Thu, 25 Apr 2019 18:00:11 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/uEDMhw1DjArAGrMvfYA8svr-c2w>
Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
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, 25 Apr 2019 08:59:38 -0000

Hi Med, all,

Regarding with the issue, I'm not convinced of the benefit to return the activated ACL statistics over signal-channel.

The idea of this draft is based on this situation (quoted from Jon's comment):
(It is) very unreliable when the inbound pipe is running full.  If the pipe is not running full, then this information can be obtained over the data channel.

ACL stats can be get over the data-channel. I don't see any reason to reproduce the same function.

Further more, I don't think the DOTS server should notify that DOTS client with the change by including the corresponding acl-* parameters in an asynchronous notification.
The basic behavior is already written in the draft:
    This specification does not require any modification to the efficacy
    update and the withdrawal procedures defined in
    [I-D.ietf-dots-signal-channel].  In particular, ACL-related clauses
    are not included in a PUT request used to send an efficacy update and
    DELETE requests.

If so, the server need not to store any resource about acl-* per mitigation request, which make the function of the signal-filter-control simple enough.

thanks,
Kaname

On 2019/04/24 15:24, mohamed.boucadair@orange.com wrote:
> Hi all,
>
> We do have one pending issue to be resolved for this draft. The issue is available at:
> https://github.com/boucadair/filter-control/issues/1
>
> We need your feedback on this.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Dots [mailto:dots-bounces@ietf.org] De la part de internet-
>> drafts@ietf.org
>> Envoyé : mercredi 24 avril 2019 07:34
>> À : i-d-announce@ietf.org
>> Cc : dots@ietf.org
>> Objet : [Dots] I-D Action: draft-ietf-dots-signal-filter-control-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.
>>
>>          Title           : Controlling Filtering Rules Using Distributed
>> Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
>>          Authors         : Kaname Nishizuka
>>                            Mohamed Boucadair
>>                            Tirumaleswar Reddy
>>                            Takahiko Nagata
>> 	Filename        : draft-ietf-dots-signal-filter-control-00.txt
>> 	Pages           : 23
>> 	Date            : 2019-04-23
>>
>> Abstract:
>>     This document specifies an extension to the DOTS signal channel so
>>     that DOTS clients can control their filtering rules when an attack
>>     mitigation is active.
>>
>>     Particularly, this extension allows a DOTS client to activate or de-
>>     activate existing filtering rules during a DDoS attack.  The
>>     characterization of these filtering rules is supposed to be conveyed
>>     by a DOTS client during an idle time by means of the DOTS data
>>     channel protocol.
>>
>> 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 Distributed Denial-
>>        of-Service Open Threat Signaling (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-ietf-dots-signal-filter-control/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter-control-
>> 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/
>>
>> _______________________________________________
>> Dots mailing list
>> Dots@ietf.org
>> https://www.ietf.org/mailman/listinfo/dots
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots