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

<mohamed.boucadair@orange.com> Mon, 29 April 2019 12:56 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 3F1E61202D9 for <dots@ietfa.amsl.com>; Mon, 29 Apr 2019 05:56:58 -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 nutWom6mdbAs for <dots@ietfa.amsl.com>; Mon, 29 Apr 2019 05:56:55 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D40120025 for <dots@ietf.org>; Mon, 29 Apr 2019 05:56:55 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 44t4Rn5cW1zBsPl; Mon, 29 Apr 2019 14:56:53 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 44t4Rn4vrxzBrLS; Mon, 29 Apr 2019 14:56:53 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 29 Apr 2019 14:56:53 +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/5ngAAUJIHAAADrVQAAAy9qAAADPe0AAAl2uEAADFwxAAACGwAA=
Date: Mon, 29 Apr 2019 12:56:52 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA6736E@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.adroo t.infra.ftgroup> <BYAPR16MB279071FE429E252221521470EA390@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA67156@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790D9396449CF75422C010CEA390@BYAPR16MB2790.namprd16.prod.outlook.com> <03f901d4fe6f$98f00a00$cad01e00$@jpshallow.com> <BYAPR16MB2790B418CFE55D99C282FA71EA390@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6725D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790D07ADECEBA6DAD156B5CEA390@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB2790D07ADECEBA6DAD156B5CEA390@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/1zyAu24JIixxsB-fFJZCi-byv7E>
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 12:56:58 -0000

Tiru, 

Looks like a candidate item in a separate DOTS telemetry specification I-D, rather than restricting it to the filter control case. 

Hope this is OK with you. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : lundi 29 avril 2019 14:47
> À : 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: Monday, April 29, 2019 5:05 PM
> > To: Konda, Tirumaleswar Reddy
> > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> > ietf@jpshallow.com>gt;; kaname nishizuka <kaname@nttv6.jp>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.
> >
> > Tiru,
> >
> > I agree that we are approaching the problem with two different use cases:
> >
> > (1) a client domain with is basically "consuming" services. I do still
> think this
> > use case does not need to learn about the ACL stats.
> 
> Yes.
> 
> >
> > (2) your case in which the client domain is "providing" services: I still
> think
> > that the impact on business can be determined also using local information
> > (known patterns + rate-limit policy applied by the client). If the goal is
> to
> > decide whether/when an alternate mitigator is to be solicited, this can
> > deterministically rely upon "status" set to 4 (Attack has exceeded the
> > mitigation provider capacity) or deactivate back the rate-limit ACL + local
> > observation. Please remember that local observation is needed for efficacy
> > update.
> 
> "Attack has exceeded" status message does not convey the details the traffic
> rate-limited, and the client needs to understand the attack scale to figure
> out suitable alternate mitigation provider.  It is a critical DOTS telemetry
> that needs to be conveyed in the signal channel and cannot be propagated in
> the data channel during an massive attack.
> 
> Cheers,
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > Envoyé : lundi 29 avril 2019 12:18
> > > À : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; kaname nishizuka;
> > > dots@ietf.org Objet : RE: [Dots]
> > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > >
> > > > -----Original Message-----
> > > > From: Jon Shallow <supjps-ietf@jpshallow.com>
> > > > Sent: Monday, April 29, 2019 3:11 PM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <TirumaleswarReddy_Konda@McAfee.com>om>;
> > > > mohamed.boucadair@orange.com; kaname nishizuka
> > <kaname@nttv6.jp>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,
> > > >
> > > > See inline,
> > > >
> > > > Regards
> > > >
> > > > Jon
> > > >
> > > > > -----Original Message-----
> > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda,
> > > > > Tirumaleswar Reddy
> > > > > Sent: 29 April 2019 10:22
> > > > > To: mohamed.boucadair@orange.com; Jon Shallow; 'kaname nishizuka';
> > > > > dots@ietf.org
> > > > > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > > Stats issue
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mohamed.boucadair@orange.com
> > > > > <mohamed.boucadair@orange.com>
> > > > > > Sent: Monday, April 29, 2019 2:46 PM
> > > > > > To: Konda, Tirumaleswar Reddy
> > > > > <TirumaleswarReddy_Konda@McAfee.com>om>;
> > > > > > Jon Shallow <supjps-ietf@jpshallow.com>om>; 'kaname nishizuka'
> > > > > > <kaname@nttv6.jp>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.
> > > > > >
> > > > > > (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.
> > > >
> > > > Is this correct?
> > > >
> > > > > >
> > > > > > >
> > > > > > > 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.
> > > > >
> > > > > I am not referring to "nominal" services or critical resources.
> > > > > For instance, consider Netflix is not accessible to a large number
> > > > > of users because of the rate-limit action.
> > > >
> > > > The DOTS server will have a limited (only because they have to be
> > > previously
> > > > defined) set of (possibly inactivated) ACLS on the server.  If the
> > > "standard"
> > > > white/black list are unable to bring the inbound pipe back to not
> > > > being flooded, then a (likely global for the DOTS client's networks)
> > > > Rate-Limit
> > > ACL
> > > > must be brought in.  Once the Inbound pipe is available, then
> > > > analysis of
> > > the
> > > > data reaching the DOTs client will show the top users which then
> > > > need their own limiting (black or rate-limit) ACL set up over the
> > > > data channel.  At
> > > this
> > > > point the Rate-Limit ACL can removed to see if things are stable again.
> > > > [I agree that the CPE may not have this top usage capability]
> > > >
> > > > If Netflix (or similar) has a priority when under attack, then this
> > > > needs
> > > to be
> > > > added into a White ACL which can be done once the inbound pipe is
> > > > not flooded (or be a part of the standard white lists)
> > >
> > > I think we are discussing two different use cases. My attack use case
> > > is Netflix content provider is under volumetric DDoS attack, and if
> > > the rate- limit ACL is configured using the DOTS signal channel
> > > because the DDoS mitigation provider cannot handle all the attack
> > > traffic. The rate-limit ACL stats will help Netflix understand the
> > > scale of the attack, impact on the current business because of the
> > > rate-limit action (e.g. based on the amount of traffic dropped by DMS,
> > > infer the amount of good traffic dropped by the rate-limit ACL action,
> > > and infer the number of users who cannot access its service), and if
> > > the attack lasts for  several days/weeks help identify an alternate
> > > mitigation provider capable of handling the attack (e.g. Krebs was
> > > initially using Akamai and eventually got protected by Google to handle
> the
> > massive attack).
> > >
> > > Cheers,
> > > -Tiru
> > >
> > > >
> > > > ~jon
> > > >
> > > > >
> > > > > -Tiru
> > > > >
> > > > > _______________________________________________
> > > > > Dots mailing list
> > > > > Dots@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/dots