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

[<[e-mail]>]

Hi Tiru, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : vendredi 26 avril 2019 16:01
> À : 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: Friday, April 26, 2019 6:38 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.
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:[e-mail]]
> > > Envoyé : vendredi 26 avril 2019 14:20
> > > À : 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: Dots <[e-mail]> On Behalf Of
> > > > [e-mail]
> > > > Sent: Friday, April 26, 2019 11:22 AM
> > > > 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.
> > > >
> > > > Hi Tiru,
> > > >
> > > > The question then is: How knowing these stats will help in softening
> > > > the impact on the "business of the victim" other than observing that
> > > > traffic is being rate-limited (which is already known to the
> > > > client)? That information will be made available anyway once the
> > > > DOTS data channel is functional
> > > again.
> > >
> > > While the DDOS attack is progress (it may last for few weeks), the ACL
> > > stats can help the client learn the scale of the DDoS attack, and can
> > > identify alternate mitigation providers capable of handling the attack
> scale.
> >
> > [Med] Wouldn't that be inferred from the aggregate stats returned in the
> > signal channel and local observation?
> 
> No, the client will not know the amount of traffic dropped by the rate-limit
> ACL.

[Med] The ACL will rate limit both attack and legitimate traffic. So, unless some "additional" information is made available to the DOTS client, the client cannot infer "the scale of the DDoS attack" from those ACL stats.

Things are different for the aggregate stats returned by the signal channel. 

> 
> >
> > >
> > > >
> > > > An example to soften such impacts could be: A DOTS client can
> > > > manipulate ACLs with different rate-limit policies that it can
> > > > activate/deactivate
> > > based on
> > > > local available information AND/OR status/aggregate stats received
> > > > via the signal channel without relying on ACL-specific stats
> > > > received from the
> > > server.
> > >
> > > If the server can provide the aggregate stats, it can also provide
> > > ACL- specific stats.
> >
> > [Med] If it can do so, it can do it also for any ACL.
> 
> The other ACLs to permit white-listed traffic or drop black-listed traffic is
> not impacting legitimate traffic to reach the target. As you already know,
> rate-limit ACL is different, it is dropping good traffic.

[Med] That's one dimension of the discussion (how to make use of shared data). The other dimension is: if the server is able to share ACL-related stats, why the functionality should be restricted to specific ACL types or as a function of the channel. 

For example, a rate limit ACL can be programmed to be automatically enabled during mitigation (data channel) or explicitly using the signal channel. Why the stats can only be shared for this ACL in the second case and not for the first case? 

> 
> >
> >  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.   

 Imagine the hot customer
> calls because its services are not available to legitimate users because of
> rate-limit action,
> the client needs to have a granular visibility (visibility is a critical
> criteria in MITRE attack framework https://attack.mitre.org/).