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

<mohamed.boucadair@orange.com> Mon, 29 April 2019 06:36 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 F0C39120074 for <dots@ietfa.amsl.com>; Sun, 28 Apr 2019 23:36:47 -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 gTU96R2aPwyn for <dots@ietfa.amsl.com>; Sun, 28 Apr 2019 23:36:45 -0700 (PDT)
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 86207120072 for <dots@ietf.org>; Sun, 28 Apr 2019 23:36:45 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 44sw175WdCz1yRV; Mon, 29 Apr 2019 08:36:43 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 44sw174qgzzyQC; Mon, 29 Apr 2019 08:36:43 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([fe80::849f:f804:b713:d99a%21]) with mapi id 14.03.0439.000; Mon, 29 Apr 2019 08:36:43 +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/QA==
Date: Mon, 29 Apr 2019 06:36:43 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA66FEC@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>
In-Reply-To: <BYAPR16MB27909F467FFE57F380015E94EA3E0@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/f_I-hF_rMQq5I05y_-zb16X9K5U>
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 06:36:48 -0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : vendredi 26 avril 2019 16:01
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka'; dots@ietf.org
> Objet : RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > Sent: Friday, April 26, 2019 6:38 PM
> > To: Konda, Tirumaleswar Reddy
> > <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-
> > ietf@jpshallow.com>; 'kaname nishizuka' <kaname@nttv6.jp>;
> > dots@ietf.org
> > Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> >
> > This email originated from outside of the organization. Do not click links
> or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > Envoyé : vendredi 26 avril 2019 14:20
> > > À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka';
> > > dots@ietf.org Objet : RE: [Dots]
> > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > >
> > > > -----Original Message-----
> > > > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > > > mohamed.boucadair@orange.com
> > > > Sent: Friday, April 26, 2019 11:22 AM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-
> > > > ietf@jpshallow.com>; 'kaname nishizuka' <kaname@nttv6.jp>;
> > > > dots@ietf.org
> > > > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > Stats issue
> > > >
> > > > This email originated from outside of the organization. Do not click
> > > > links
> > > or
> > > > open attachments unless you recognize the sender and know the
> > > > content is safe.
> > > >
> > > > Hi Tiru,
> > > >
> > > > The question then is: How knowing these stats will help in softening
> > > > the impact on the "business of the victim" other than observing that
> > > > traffic is being rate-limited (which is already known to the
> > > > client)? That information will be made available anyway once the
> > > > DOTS data channel is functional
> > > again.
> > >
> > > While the DDOS attack is progress (it may last for few weeks), the ACL
> > > stats can help the client learn the scale of the DDoS attack, and can
> > > identify alternate mitigation providers capable of handling the attack
> scale.
> >
> > [Med] Wouldn't that be inferred from the aggregate stats returned in the
> > signal channel and local observation?
> 
> No, the client will not know the amount of traffic dropped by the rate-limit
> ACL.

[Med] The ACL will rate limit both attack and legitimate traffic. So, unless some "additional" information is made available to the DOTS client, the client cannot infer "the scale of the DDoS attack" from those ACL stats.

Things are different for the aggregate stats returned by the signal channel. 

> 
> >
> > >
> > > >
> > > > An example to soften such impacts could be: A DOTS client can
> > > > manipulate ACLs with different rate-limit policies that it can
> > > > activate/deactivate
> > > based on
> > > > local available information AND/OR status/aggregate stats received
> > > > via the signal channel without relying on ACL-specific stats
> > > > received from the
> > > server.
> > >
> > > If the server can provide the aggregate stats, it can also provide
> > > ACL- specific stats.
> >
> > [Med] If it can do so, it can do it also for any ACL.
> 
> The other ACLs to permit white-listed traffic or drop black-listed traffic is
> not impacting legitimate traffic to reach the target. As you already know,
> rate-limit ACL is different, it is dropping good traffic.

[Med] That's one dimension of the discussion (how to make use of shared data). The other dimension is: if the server is able to share ACL-related stats, why the functionality should be restricted to specific ACL types or as a function of the channel. 

For example, a rate limit ACL can be programmed to be automatically enabled during mitigation (data channel) or explicitly using the signal channel. Why the stats can only be shared for this ACL in the second case and not for the first case? 

> 
> >
> >  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.   

 Imagine the hot customer
> calls because its services are not available to legitimate users because of
> rate-limit action,
> the client needs to have a granular visibility (visibility is a critical
> criteria in MITRE attack framework https://attack.mitre.org/).