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

[kaname nishizuka <[e-mail]>]

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