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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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