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