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

[<[e-mail]>]

Hi Kaname, 

Thank you for double checking.

This confirms the initial assessment on the stability of filter-control I-D. 

Cheers,
Med

> -----Message d'origine-----
> De : kaname nishizuka [mailto:[e-mail]]
> Envoyé : lundi 22 juillet 2019 14:37
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]
> Objet : Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> 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