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

<mohamed.boucadair@orange.com> Mon, 29 April 2019 09:16 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 01CE31200E6 for <dots@ietfa.amsl.com>; Mon, 29 Apr 2019 02:16:16 -0700 (PDT)
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 uLxnoso6kqz3 for <dots@ietfa.amsl.com>; Mon, 29 Apr 2019 02:16:14 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7760E1200F8 for <dots@ietf.org>; Mon, 29 Apr 2019 02:16:14 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 44szY83db5zCsFp; Mon, 29 Apr 2019 11:16:12 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 44szY85mMbzDq7r; Mon, 29 Apr 2019 11:16:12 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM21.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 29 Apr 2019 11:16:12 +0200
From: <mohamed.boucadair@orange.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "Jon Shallow" <supjps-ietf@jpshallow.com>, 'kaname nishizuka' <kaname@nttv6.jp>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
Thread-Index: AdT6ZmI8uG0f606MQBW+/9uvcTWn6QA3ueOAAAD5v4AAAuISAAACLWCwAASh2bAAAFNQMAAALZggAB/gx7AADZnDQAAB9k5gAAGY4eAAh04/QAAA/5ngAAUJIHA=
Date: Mon, 29 Apr 2019 09:16:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA67156@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <c3c9614f-908a-c132-cd35-6c627e341f2b@nttv6.jp> <012601d4fb49$3328c000$997a4000$@jpshallow.com> <BYAPR16MB279020119E24ADCB54B339E3EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6591A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27903D8D208FA3AC951FDEE4EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA65AD6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB279013E8029BE0294293A333EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6623D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790146175B845622B2EF438EA3E0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6649C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27909F467FFE57F380015E94EA3E0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA66FEC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB279071FE429E252221521470EA390@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB279071FE429E252221521470EA390@BYAPR16MB2790.namprd16.prod.outlook.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/-59KLkWFK3hxhHR__kzZEYF99X0>
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: Mon, 29 Apr 2019 09:16:16 -0000

(Focusing on this particular point).


> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : lundi 29 avril 2019 10:52
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka'; dots@ietf.org
> Objet : RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> > > >
> > > >  ACL-specific stats and mitigation stats will give a clear
> > > > > picture of the traffic rate-limited, bad traffic dropped by the
> > > > > DDoS mitigation system, and using these stats the DOTS client can
> > > > > heuristically determine the amount of legitimate traffic dropped
> > > > > because of rate-limit and the impact of the attack on its service.
> > > >
> > > > [Med] The impact can be observed locally (e.g., bad QoS, inability
> > > > to
> > > access a
> > > > service, instable connectivity, etc.). I still don’t see how sharing
> > > > the
> > > ACL stats
> > > > will be helpful here.
> > > >
> > > > A DOTS client can preinstall the same rate-limit filter with but
> > > > with
> > > different
> > > > policies. It can select the appropriate ACL to activate/deactivate
> > > > based on local experience.
> > >
> > > I don't get how the local experience will help the client pick an
> > > alternate mitigation provider who can handle the attack scale.
> >
> > [Med] Modern CPEs include automated features to assess the availability of
> > services such as VoIP, IPTV, etc. The DOTS client can be fed with input
> from
> > these modules and react accordingly.

[Med] s/client/server.

> 
> I meant the target network cannot infer the amount of legitimate traffic (or
> infer the number of users) unable to use its service because of the rate-
> limit action.
> 

[Med] The amount of traffic is not required to assess the availability of "nominal" services (the example above). What is really important is whether some critical services are available. That information can be determined without needing the ACL stats.