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

[<[e-mail]>]

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

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