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

[<[e-mail]>]

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