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

[kaname nishizuka <[e-mail]>]

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, [e-mail] 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:[e-mail]]
>> Envoyé : mardi 30 avril 2019 16:24
>> À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Jon Shallow;
>> [e-mail]
>> 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: [e-mail]
>>>> <[e-mail]>
>>>> Sent: Monday, April 29, 2019 6:27 PM
>>>> To: Konda, Tirumaleswar Reddy
>>>> <[e-mail]>; Jon Shallow <supjps-
>>>> [e-mail]>; kaname nishizuka <[e-mail]>; [e-mail]
>>>> 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:[e-mail]]
>>>>> Envoyé : lundi 29 avril 2019 14:47
>>>>> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; kaname nishizuka;
>>>>> [e-mail] Objet : RE: [Dots]
>>>>> (draft-ietf-dots-signal-filter-control) ACL Stats issue
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail]
>>>>>> <[e-mail]>
>>>>>> Sent: Monday, April 29, 2019 5:05 PM
>>>>>> To: Konda, Tirumaleswar Reddy
>>>>>> <[e-mail]>; Jon Shallow <supjps-
>>>>>> [e-mail]>; kaname nishizuka <[e-mail]>;
>>>>>> [e-mail]
>>>>>> 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:[e-mail]]
>>>>>>> Envoyé : lundi 29 avril 2019 12:18 À : Jon Shallow; BOUCADAIR
>>>>>>> Mohamed TGI/OLN; kaname nishizuka; [e-mail] Objet : RE:
>>>>>>> [Dots]
>>>>>>> (draft-ietf-dots-signal-filter-control) ACL Stats issue
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jon Shallow <[e-mail]>
>>>>>>>> Sent: Monday, April 29, 2019 3:11 PM
>>>>>>>> To: Konda, Tirumaleswar Reddy
>>>>>>>> <[e-mail]>;
>>>>>>>> [e-mail]; kaname nishizuka
>>>>>> <[e-mail]>;
>>>>>>>> [e-mail]
>>>>>>>> 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: [e-mail]] On Behalf Of Konda,
>>>>>>>>> Tirumaleswar Reddy
>>>>>>>>> Sent: 29 April 2019 10:22
>>>>>>>>> To: [e-mail]; Jon Shallow; 'kaname
>>>>>>>>> nishizuka'; [e-mail]
>>>>>>>>> Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control)
>>>>>>>>> ACL Stats issue
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [e-mail]
>>>>>>>>> <[e-mail]>
>>>>>>>>>> Sent: Monday, April 29, 2019 2:46 PM
>>>>>>>>>> To: Konda, Tirumaleswar Reddy
>>>>>>>>> <[e-mail]>;
>>>>>>>>>> Jon Shallow <[e-mail]>; 'kaname nishizuka'
>>>>>>>>>> <[e-mail]>; [e-mail]
>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>> Envoyé : lundi 29 avril 2019 10:52 À : BOUCADAIR Mohamed
>>>>>>>>>>> TGI/OLN; Jon Shallow; 'kaname nishizuka'; [e-mail]
>>>>>>>>>>> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots