Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
kaname nishizuka <kaname@nttv6.jp> Mon, 22 July 2019 12:37 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 7D5DF120295 for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 05:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 X9SU9rdkhjIc for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 05:36:56 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id A51C9120291 for <dots@ietf.org>; Mon, 22 Jul 2019 05:36:56 -0700 (PDT)
Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 2E39825F6BD; Mon, 22 Jul 2019 21:36:54 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1563799014; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SjCIR1l/SipGhEdEJ3PakLBgE8S+Vc6uoPJtwNUiFdo=; b=h6kz3w+ZTnmqud17lIYY8v60Mts8w9N7Dv+MxDuxS1937HAdFosD+GKkDEeuRI15VH3Nf+ m7BxefSwhZV0h6uT1rj2PbP3e2TqEu1uZPFK7ZRJu5jKXzUiesKW/jXHu99ZV/JHTL2Vda 41k7maTTxCFopC4IoOBb2ONFXHnwSaY=
Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 22A6C75907D; Mon, 22 Jul 2019 21:36:51 +0900 (JST)
To: mohamed.boucadair@orange.com
Cc: "dots@ietf.org" <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.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> <787AE7BB302AE849A7480A190F8B93302EA6736E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790A37C1A6980D996B92B6CEA390@BYAPR16MB2790.namprd16.prod.outlook.com> <ee351f86-a36d-1e2d-ab02-418a7359285e@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302EAE4D52@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: kaname nishizuka <kaname@nttv6.jp>
Message-ID: <5462fbf7-5cc8-d533-4e97-cd7595ee094b@nttv6.jp>
Date: Mon, 22 Jul 2019 21:36:47 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAE4D52@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/byCqEXsVCBqWJQoM-9RoIKng-nk>
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, 22 Jul 2019 12:37:05 -0000
Hi Med, I've read the telemetry I-D and will make a support comment later. Then, there was no concern about any duplicated spec with the signal-filter-control I-D. The signal-filter-control I-D can be ready for WGLC as it is. Thank you for taking care of it. regards, Kaname On 2019/07/16 17:05, mohamed.boucadair@orange.com wrote: > Hi Kaname, > >> I'd like to check the new DOTS telemetry specification I-D and see if a >> reference from the signal-filter-control is needed. > Now that the telemetry I-D is available (https://tools.ietf.org/html/draft-reddy-dots-telemetry-00), please let us know whether you have comments. Thanks. > > Cheers, > Med > >> -----Message d'origine----- >> De : kaname nishizuka [mailto:kaname@nttv6.jp] >> Envoyé : mardi 30 avril 2019 16:24 >> À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Jon Shallow; >> dots@ietf.org >> Objet : Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue >> >> Hi, >> >> > Looks like a candidate item in a separate DOTS telemetry specification >> I-D, >> rather than restricting it to the filter control case. >> I agree with this. >> At the usecase(2) that Tiru raised, per ACL traffic counter would be >> useful but it's not limited to the ACLs activated by signal-filter- >> control. >> "activate-when-mitigating" ACL related information is one of the example. >> It can be decoupled with the resources created by a signal-filter-control. >> >> I'm in favor of this Jon's comment because it clarifies the original >> behavior of a signal-filter-control. >> > 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'd like to check the new DOTS telemetry specification I-D and see if a >> reference from the signal-filter-control is needed. >> >> regards, >> Kaname >> >> >> On 2019/04/29 21:58, Konda, Tirumaleswar Reddy wrote: >>>> -----Original Message----- >>>> From: mohamed.boucadair@orange.com >>>> <mohamed.boucadair@orange.com> >>>> Sent: Monday, April 29, 2019 6:27 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. >>>> >>>> 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. >>> Yes, works for me. >>> >>> -Tiru >>> >>>> 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>; 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. >>>>>> >>>>>> 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>; >>>>>>>> mohamed.boucadair@orange.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, >>>>>>>> >>>>>>>> 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>; >>>>>>>>>> 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. >>>>>>>>>> (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
- [Dots] (draft-ietf-dots-signal-filter-control) AC… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… kaname nishizuka
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Jon Shallow
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Jon Shallow
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… Konda, Tirumaleswar Reddy
- Re: [Dots] (draft-ietf-dots-signal-filter-control… kaname nishizuka
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair
- Re: [Dots] (draft-ietf-dots-signal-filter-control… kaname nishizuka
- Re: [Dots] (draft-ietf-dots-signal-filter-control… mohamed.boucadair