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

From: <[email-masked]>
Date: Wed, 24 Apr 2019 06:24:35 +0000

Hi all, 

We do have one pending issue to be resolved for this draft. The issue is available at: 
https://github.com/boucadair/filter-control/issues/1 

We need your feedback on this. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : mercredi 24 avril 2019 07:34
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Dots] I-D Action: draft-ietf-dots-signal-filter-control-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.
> 
>         Title           : Controlling Filtering Rules Using Distributed
> Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
>         Authors         : Kaname Nishizuka
>                           Mohamed Boucadair
>                           Tirumaleswar Reddy
>                           Takahiko Nagata
> 	Filename        : draft-ietf-dots-signal-filter-control-00.txt
> 	Pages           : 23
> 	Date            : 2019-04-23
> 
> Abstract:
>    This document specifies an extension to the DOTS signal channel so
>    that DOTS clients can control their filtering rules when an attack
>    mitigation is active.
> 
>    Particularly, this extension allows a DOTS client to activate or de-
>    activate existing filtering rules during a DDoS attack.  The
>    characterization of these filtering rules is supposed to be conveyed
>    by a DOTS client during an idle time by means of the DOTS data
>    channel protocol.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>    Please update these statements within the document with the RFC
>    number to be assigned to this document:
> 
>    o  "This version of this YANG module is part of RFC XXXX;"
> 
>    o  "RFC XXXX: Controlling Filtering Rules Using Distributed Denial-
>       of-Service Open Threat Signaling (DOTS) Signal Channel";
> 
>    o  reference: RFC XXXX
> 
>    o  [RFCXXXX]
> 
>    Please update these statements with the RFC number to be assigned to
>    the following documents:
> 
>    o  "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling
>       (DOTS) Signal Channel Specification" (used to be
>       [I-D.ietf-dots-signal-channel])
> 
>    o  "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling
>       (DOTS) Data Channel Specification" (used to be
>       [I-D.ietf-dots-data-channel])
> 
>    Please update the "revision" date of the YANG module.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter-control-
> 00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 25 Apr 2019 18:00:11 +0900

Hi Med, all,

Regarding with the issue, I'm not convinced of the benefit to return the activated ACL statistics over signal-channel.

The idea of this draft is based on this situation (quoted from Jon's comment):
(It is) very unreliable when the inbound pipe is running full.  If the pipe is not running full, then this information can be obtained over the data channel.

ACL stats can be get over the data-channel. I don't see any reason to reproduce the same function.

Further more, I don't think the DOTS server should notify that DOTS client with the change by including the corresponding acl-* parameters in an asynchronous notification.
The basic behavior is already written in the draft:
    This specification does not require any modification to the efficacy
    update and the withdrawal procedures defined in
    [I-D.ietf-dots-signal-channel].  In particular, ACL-related clauses
    are not included in a PUT request used to send an efficacy update and
    DELETE requests.

If so, the server need not to store any resource about acl-* per mitigation request, which make the function of the signal-filter-control simple enough.

thanks,
Kaname

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 25 Apr 2019 10:28:07 +0100

Hi there,

The advantage of separating out the counters for the different ACLs is that the DOTS client can then determine what is being effective or not.  However, if (signal) data is able to get from the DOTS server to the DOTS client, then it is likely that the data channel will still be operable and can be used to get these numbers so I still do not think that this should be over the signal channel.

I think that that the GET response (or observe response) bytes-dropped etc. should be the total dropped - i.e. the sum of the ACls and what the DMS is otherwise doing as it refers to the mitigation request.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of kaname
> nishizuka
> Sent: 25 April 2019 10:00
> To: [email-masked]; [email-masked]
> Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> Hi Med, all,
> 
> Regarding with the issue, I'm not convinced of the benefit to return the
> activated ACL statistics over signal-channel.
> 
> (It is) very unreliable when the inbound pipe is running full.  If the pipe is not
> running full, then this information can be obtained over the data channel.
> 
> Further more, I don't think the DOTS server should notify that DOTS client
> with the change by including the corresponding acl-* parameters in an
> asynchronous notification.
> If so, the server need not to store any resource about acl-* per mitigation
> request, which make the function of the signal-filter-control simple enough.
> 
> thanks,
> Kaname
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Apr 2019 11:03:34 +0000

> From: Dots <[email-masked]> On Behalf Of Jon Shallow
> Sent: Thursday, April 25, 2019 2:58 PM
> To: 'kaname nishizuka' <[email-masked]>;
> [email-masked]; [email-masked]
> 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 there,
> 
> The advantage of separating out the counters for the different ACLs is that
> the DOTS client can then determine what is being effective or not.  However,
> if (signal) data is able to get from the DOTS server to the DOTS client, then it
> is likely that the data channel will still be operable and can be used to get
> these numbers so I still do not think that this should be over the signal
> channel.
> 
> I think that that the GET response (or observe response) bytes-dropped etc.
> should be the total dropped - i.e. the sum of the ACls and what the DMS is
> otherwise doing as it refers to the mitigation request.

If the DOTS server knows the traffic dropped by ACLs and the traffic dropped by DMS, why can't it provide this statistics separately instead of summing it.  If the incoming link is saturated, data channel will not function  but signal channel (using UDP) will work and there is a good possibility that one of the GET responses periodically sent will reach the client (As you already know, DOTS signal channel is tolerant to high packet loss in one direction).

-Tiru

> > Regarding with the issue, I'm not convinced of the benefit to return
> > the activated ACL statistics over signal-channel.
> >
> > (It is) very unreliable when the inbound pipe is running full.  If the
> > pipe is not running full, then this information can be obtained over the data
> channel.
> >
> > Further more, I don't think the DOTS server should notify that DOTS
> > client with the change by including the corresponding acl-* parameters
> > in an asynchronous notification.
> > If so, the server need not to store any resource about acl-* per
> > mitigation request, which make the function of the signal-filter-control
> simple enough.
> >
> > thanks,
> > Kaname
> >
> > > We do have one pending issue to be resolved for this draft. The
> > > issue is
> > available at:
> > >> [email-masked] Envoyé : mercredi 24 avril 2019 07:34 À :
> > >> [email-masked] Cc : [email-masked] Objet : [Dots] I-D Action:
> > >> draft-ietf-dots-signal-filter-control-00.txt
> > >>
> > >>
> > >> This draft is a work item of the DDoS Open Threat Signaling WG of
> > >> the
> > IETF.
> > >>

---

From: <[email-masked]>
Date: Thu, 25 Apr 2019 12:07:18 +0000

Tiru, 

Even if we assume that ACL-specific stats can be communicated via the signal channel (which we don't have an agreement on it so far), this is not specific to the filter-control spec but the same reasoning would apply for all ACLs instructed by the DOTS client (not only those that are adjusted during attack times).

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 25 avril 2019 13:04
> À : Jon Shallow; 'kaname nishizuka'; BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> If the DOTS server knows the traffic dropped by ACLs and the traffic dropped
> by DMS, why can't it provide this statistics separately instead of summing
> it.  If the incoming link is saturated, data channel will not function  but
> signal channel (using UDP) will work and there is a good possibility that one
> of the GET responses periodically sent will reach the client (As you already
> know, DOTS signal channel is tolerant to high packet loss in one direction).
> 
> -Tiru
> 
> >
> > Regards
> >
> > Jon
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Apr 2019 14:13:00 +0000

> From: [email-masked]
> <[email-masked]>
> Sent: Thursday, April 25, 2019 5:37 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Jon Shallow <supjps-
> [email-masked]>; 'kaname nishizuka' <[email-masked]>;
> [email-masked]
> Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> 
> 
> Tiru,
> 
> Even if we assume that ACL-specific stats can be communicated via the signal
> channel (which we don't have an agreement on it so far), this is not specific
> to the filter-control spec but the same reasoning would apply for all ACLs
> instructed by the DOTS client (not only those that are adjusted during attack
> times).

My point is, If the ACL is activated using the signal channel, since the ACL is part of the mitigation request, only the activated ACL stats needs to be conveyed in the mitigation status.  Other ACLs activated using data channel are not part of mitigation request, 
so no need to convey their stats using the signal channel.

-Tiru

> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : Jon Shallow; 'kaname nishizuka'; BOUCADAIR Mohamed TGI/OLN;
> > [email-masked] Objet : 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 there,
> > >
> > > The advantage of separating out the counters for the different ACLs
> > > is that the DOTS client can then determine what is being effective or not.
> > However,
> > > if (signal) data is able to get from the DOTS server to the DOTS
> > > client,
> > then it
> > > is likely that the data channel will still be operable and can be
> > > used to
> > get
> > > these numbers so I still do not think that this should be over the
> > > signal channel.
> > >
> > > should be the total dropped - i.e. the sum of the ACls and what the
> > > DMS is otherwise doing as it refers to the mitigation request.
> >
> > If the DOTS server knows the traffic dropped by ACLs and the traffic
> > dropped by DMS, why can't it provide this statistics separately
> > instead of summing it.  If the incoming link is saturated, data
> > channel will not function  but signal channel (using UDP) will work
> > and there is a good possibility that one of the GET responses
> > periodically sent will reach the client (As you already know, DOTS signal
> channel is tolerant to high packet loss in one direction).
> >
> > -Tiru
> >
> > >
> > > Regards
> > >
> > > Jon
> > >
> > > > Regarding with the issue, I'm not convinced of the benefit to
> > > > return the activated ACL statistics over signal-channel.
> > > >
> > > > The idea of this draft is based on this situation (quoted from
> > > > Jon's
> > > > comment):
> > > > (It is) very unreliable when the inbound pipe is running full.  If
> > > > the pipe is not running full, then this information can be
> > > > obtained over the
> > data
> > > channel.
> > > >
> > > > Further more, I don't think the DOTS server should notify that
> > > > DOTS client with the change by including the corresponding acl-*
> > > > parameters in an asynchronous notification.
> > > > >> De : Dots [mailto:[email-masked]] De la part de
> > > > >> internet- [email-masked] Envoyé : mercredi 24 avril 2019 07:34 À :
> > > > >> A New Internet-Draft is available from the on-line
> > > > >> Internet-Drafts directories.
> > > > >> This draft is a work item of the DDoS Open Threat Signaling WG
> > > > >> of the
> > > > IETF.
> > > > >>
> > > > >>     Particularly, this extension allows a DOTS client to
> > > > >> activate or
> > de-
> > > > >>     Please update these statements with the RFC number to be
> > > > >> assigned
> > > to
> > > > >>     the following documents:
> > > > >>
> > > > >> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-
> > > > >> cont
> > > > >> rol/
> > > > >>
> > > > >> https://tools.ietf.org/html/draft-ietf-dots-signal-filter-contr
> > > > >> ol-0
> > > > >> 0
> > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-fi
> > > > >> lter
> > > > >> -control-
> > > > >> 00
> > > > >>
> > > > >>
> > > > >> Please note that it may take a couple of minutes from the time
> > > > >> of
> > > > submission

---

From: <[email-masked]>
Date: Thu, 25 Apr 2019 14:17:46 +0000

Re-,

Why it would be useful to share stats for ACLs activated via the signal channel but not for (pre-installed) ACLs that are automatically activated during mitigations?

Cheers,
Med

> Envoyé : jeudi 25 avril 2019 16:13
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka'; [email-masked]
> My point is, If the ACL is activated using the signal channel, since the ACL
> is part of the mitigation request, only the activated ACL stats needs to be
> conveyed in the mitigation status.  Other ACLs activated using data channel
> are not part of mitigation request,
> > > > > >>     This document specifies an extension to the DOTS signal
> channel
> > so

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Apr 2019 14:26:16 +0000

> Sent: Thursday, April 25, 2019 7:48 PM
> Why it would be useful to share stats for ACLs activated via the signal channel
> but not for (pre-installed) ACLs that are automatically activated during
> mitigations ?

The rate-limit ACL activated via the signal channel is a last resort employed by the DOTS client to mitigate the volumetric attack, it has an adverse effect of blocking not just the attack traffic but also legitimate traffic, and potentially impacts the business of the victim (e.g. good users cannot leverage its service), hence it's stats look more critical to me. 

-Tiru

> > À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka';
> > > Even if we assume that ACL-specific stats can be communicated via
> > > the
> > signal
> > > to the filter-control spec but the same reasoning would apply for
> > > all ACLs instructed by the DOTS client (not only those that are
> > > adjusted during
> > attack
> > > times).
> >
> > My point is, If the ACL is activated using the signal channel, since
> > the ACL is part of the mitigation request, only the activated ACL
> > stats needs to be conveyed in the mitigation status.  Other ACLs
> > activated using data channel are not part of mitigation request, so no
> > need to convey their stats using the signal channel.
> >
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > Envoyé : jeudi 25 avril 2019 13:04 À : Jon Shallow; 'kaname
> > > > nishizuka'; BOUCADAIR Mohamed TGI/OLN; [email-masked] Objet : RE:
> > > > [Dots]
> > > > > This email originated from outside of the organization. Do not
> > > > > click links
> > > > or
> > > > > The advantage of separating out the counters for the different
> > > > > ACLs is that the DOTS client can then determine what is being
> > > > > effective or
> > not.
> > > > However,
> > > > > is likely that the data channel will still be operable and can
> > > > > be used to
> > > > get
> > > > > these numbers so I still do not think that this should be over
> > > > > the signal channel.
> > > > >
> > > > > I think that that the GET response (or observe response)
> > > > > bytes-dropped
> > > etc.
> > > > > should be the total dropped - i.e. the sum of the ACls and what
> > > > > the DMS is otherwise doing as it refers to the mitigation request.
> > > >
> > > > If the DOTS server knows the traffic dropped by ACLs and the
> > > > traffic dropped by DMS, why can't it provide this statistics
> > > > separately instead of summing it.  If the incoming link is
> > > > saturated, data channel will not function  but signal channel
> > > > (using UDP) will work and there is a good possibility that one of
> > > > the GET responses periodically sent will reach the client (As you
> > > > already know, DOTS signal
> > > > > > (It is) very unreliable when the inbound pipe is running full.
> > > > > > If the pipe is not running full, then this information can be
> > > > > > obtained over the
> > > > data
> > > > > channel.
> > > > > >
> > > > > > DOTS client with the change by including the corresponding
> > > > > > acl-* parameters in an asynchronous notification.
> > > > > >     This specification does not require any modification to
> > > > > > the
> > efficacy
> > > > > >     [I-D.ietf-dots-signal-channel].  In particular,
> > > > > > ACL-related
> > clauses
> > > > > >     are not included in a PUT request used to send an efficacy
> > > > > > update
> > and
> > > > > >     DELETE requests.
> > > > > >
> > > > > > If so, the server need not to store any resource about acl-*
> > > > > > per mitigation request, which make the function of the
> > > > > > signal-filter-control
> > > > > simple enough.
> > > > > >
> > > > > > thanks,
> > > > > > Kaname
> > > > > >
> > > > > > > We do have one pending issue to be resolved for this draft.
> > > > > > > The issue is
> > > > > > available at:
> > > > > > >> -----Message d'origine----- De : Dots
> > > > > > >> [mailto:[email-masked]] De la part de
> > > > > > >> internet- [email-masked] Envoyé : mercredi 24 avril 2019
> > > > > > >> 07:34 À
> > :
> > > > > > >> This draft is a work item of the DDoS Open Threat Signaling
> > > > > > >> WG of the
> > > > > > IETF.
> > > > > > >>
> > > > > > >>     that DOTS clients can control their filtering rules
> > > > > > >> when an
> > attack
> > > > > > >>     mitigation is active.
> > > > > > >>
> > > > > > >>     characterization of these filtering rules is supposed
> > > > > > >> to be
> > > > conveyed
> > > > > > >>     Please update these statements within the document with
> > > > > > >> the
> > > RFC
> > > > > > >>     o  "RFC XXXX: Controlling Filtering Rules Using
> > > > > > >> Distributed
> > > > Denial-
> > > > > > >>     Please update these statements with the RFC number to
> > > > > > >> be assigned
> > > > > to
> > > > > > >>     the following documents:
> > > > > > >>
> > > > > > >> Please note that it may take a couple of minutes from the
> > > > > > >> time of
> > > > > > submission

---

From: <[email-masked]>
Date: Fri, 26 Apr 2019 05:52:09 +0000

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.

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. 

Cheers,
Med

> Envoyé : jeudi 25 avril 2019 16:26
> The rate-limit ACL activated via the signal channel is a last resort employed
> by the DOTS client to mitigate the volumetric attack, it has an adverse
> effect of blocking not just the attack traffic but also legitimate traffic,
> and potentially impacts the business of the victim (e.g. good users cannot
> leverage its service), hence it's stats look more critical to me.
> 
> -Tiru
> 
> >
> > Cheers,
> > Med
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 26 Apr 2019 12:20:05 +0000

> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Friday, April 26, 2019 11:22 AM
> 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.

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

Cheers,
-Tiru

> > > Why it would be useful to share stats for ACLs activated via the
> > > signal
> > channel
> > > but not for (pre-installed) ACLs that are automatically activated
> > > during mitigations ?
> >
> > The rate-limit ACL activated via the signal channel is a last resort
> > employed by the DOTS client to mitigate the volumetric attack, it has
> > an adverse effect of blocking not just the attack traffic but also
> > legitimate traffic, and potentially impacts the business of the victim
> > (e.g. good users cannot leverage its service), hence it's stats look more
> critical to me.
> >
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > Envoyé : jeudi 25 avril 2019 16:13 À : BOUCADAIR Mohamed TGI/OLN;
> > > > Jon Shallow; 'kaname nishizuka'; [email-masked] Objet : RE: [Dots]
> > > > > Even if we assume that ACL-specific stats can be communicated
> > > > > via the
> > > > signal
> > > > > channel (which we don't have an agreement on it so far), this is
> > > > > not
> > > > specific
> > > > > to the filter-control spec but the same reasoning would apply
> > > > > for all ACLs instructed by the DOTS client (not only those that
> > > > > are adjusted during
> > > > attack
> > > > > times).
> > > >
> > > > My point is, If the ACL is activated using the signal channel,
> > > > since the ACL is part of the mitigation request, only the
> > > > activated ACL stats needs to be conveyed in the mitigation status.
> > > > Other ACLs activated using data channel are not part of mitigation
> > > > request, so no need to convey their stats using the signal channel.
> > > >
> > > > -Tiru
> > > >
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > > 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 there,
> > > > > > >
> > > > > > > The advantage of separating out the counters for the
> > > > > > > different ACLs is that the DOTS client can then determine
> > > > > > > what is being effective or
> > > > not.
> > > > > > However,
> > > > > > > if (signal) data is able to get from the DOTS server to the
> > > > > > > DOTS client,
> > > > > > then it
> > > > > > > is likely that the data channel will still be operable and
> > > > > > > can be used to
> > > > > > get
> > > > > > > these numbers so I still do not think that this should be
> > > > > > > over the signal channel.
> > > > > > >
> > > > > > > should be the total dropped - i.e. the sum of the ACls and
> > > > > > > what the DMS is otherwise doing as it refers to the mitigation
> request.
> > > > > >
> > > > > > (using UDP) will work and there is a good possibility that one
> > > > > > of the GET responses periodically sent will reach the client
> > > > > > (As you already know, DOTS signal
> > > > > > > > From: Dots [mailto: [email-masked]] On Behalf Of
> > > > > > > > kaname nishizuka
> > > > > > > > Subject: Re: [Dots]
> > > > > > > > Regarding with the issue, I'm not convinced of the benefit
> > > > > > > > to return the activated ACL statistics over signal-channel.
> > > > > > > >
> > > > > > > > The idea of this draft is based on this situation (quoted
> > > > > > > > from Jon's
> > > > > > > > comment):
> > > > > > > > If the pipe is not running full, then this information can
> > > > > > > > be obtained over the
> > > > > > data
> > > > > > > channel.
> > > > > > > >
> > > > > > > > ACL stats can be get over the data-channel. I don't see
> > > > > > > > any reason to reproduce the same function.
> > > > > > > >
> > > > > > > > Further more, I don't think the DOTS server should notify
> > > > > > > > that DOTS client with the change by including the
> > > > > > > > corresponding
> > > > > > > >     This specification does not require any modification
> > > > > > > > to the
> > > > efficacy
> > > > > > > >     are not included in a PUT request used to send an
> > > > > > > > efficacy update
> > > > and
> > > > > > > >     DELETE requests.
> > > > > > > >
> > > > > > > > If so, the server need not to store any resource about
> > > > > > > > acl-* per mitigation request, which make the function of
> > > > > > > > the signal-filter-control
> > > > > > > simple enough.
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > > Kaname
> > > > > > > >
> > > > > > > > >> [email-masked] Cc : [email-masked] Objet : [Dots]
> > > > > > > > >> I-D
> > > > Action:
> > > > > > > > >> This draft is a work item of the DDoS Open Threat
> > > > > > > > >> Signaling WG of the
> > > > > > > > IETF.
> > > > > > > > >>
> > > > > > > > >>     Particularly, this extension allows a DOTS client
> > > > > > > > >> to activate or
> > > > > > de-
> > > > > > > > >>     characterization of these filtering rules is
> > > > > > > > >> supposed to be
> > > > > > conveyed
> > > > > > > > >>     by a DOTS client during an idle time by means of
> > > > > > > > >> the DOTS
> > data
> > > > > > > > >>     channel protocol.
> > > > > > > > >>
> > > > > > > > >>     Please update these statements within the document
> > > > > > > > >> with the
> > > > > RFC
> > > > > > > > >>     Please update these statements with the RFC number
> > > > > > > > >> to be assigned
> > > > > > > to
> > > > > > > > >>     the following documents:
> > > > > > > > >>
> > > > > > > > >>     o  "RFC SSSS: Distributed Denial-of-Service Open
> > > > > > > > >> Threat
> > > > Signaling
> > > > > > > > >>     o  "RFC DDDD: Distributed Denial-of-Service Open
> > > > > > > > >> Threat
> > > > Signaling
> > > > > > > > >> https://datatracker.ietf.org/doc/draft-ietf-dots-signal
> > > > > > > > >> -fil
> > > > > > > > >> ter-
> > > > > > > > >> cont
> > > > > > > > >> rol/
> > > > > > > > >>
> > > > > > > > >> https://tools.ietf.org/html/draft-ietf-dots-signal-filt
> > > > > > > > >> er-c
> > > > > > > > >> ontr
> > > > > > > > >> ol-0
> > > > > > > > >> 0
> > > > > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-s
> > > > > > > > >> igna
> > > > > > > > >> l-fi
> > > > > > > > >> lter
> > > > > > > > >> -control-
> > > > > > > > >> 00
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> Please note that it may take a couple of minutes from
> > > > > > > > >> the time of
> > > > > > > > submission

---

From: <[email-masked]>
Date: Fri, 26 Apr 2019 13:07:54 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 26 avril 2019 14:20
> 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?

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

 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. 

> > > > > > > > > >>          Title           : Controlling Filtering Rules
> Using
> > > > > > > Distributed
> > > > > > > > > >> 	Filename        : draft-ietf-dots-signal-filter-
> control-
> > > 00.txt
> > > > > > > > > >> 	Pages           : 23
> > > > > > > > > >> 	Date            : 2019-04-23
> > > > > > > > > >>
> > > > > > > > > >> Abstract:
> > > > > > > > > >>     activate existing filtering rules during a DDoS
> attack.
> > > The

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 26 Apr 2019 14:00:31 +0000

> Sent: Friday, April 26, 2019 6:38 PM
> > > 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.
> 

No, the client will not know the amount of traffic dropped by the rate-limit ACL.

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

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.

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

Cheers,
-Tiru

> > > > Envoyé : jeudi 25 avril 2019 16:26 À : BOUCADAIR Mohamed TGI/OLN;
> > > > > but not for (pre-installed) ACLs that are automatically
> > > > > activated during mitigations ?
> > > >
> > > > The rate-limit ACL activated via the signal channel is a last
> > > > resort employed by the DOTS client to mitigate the volumetric
> > > > attack, it has an adverse effect of blocking not just the attack
> > > > traffic but also legitimate traffic, and potentially impacts the
> > > > business of the victim (e.g. good users cannot leverage its
> > > > service), hence it's stats look more
> > > critical to me.
> > > >
> > > > -Tiru
> > > >
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > Envoyé : jeudi 25 avril 2019 16:13 À : BOUCADAIR Mohamed
> > > > > > TGI/OLN; Jon Shallow; 'kaname nishizuka'; [email-masked] Objet
> > > > > > : RE: [Dots]
> > > > > > > Even if we assume that ACL-specific stats can be
> > > > > > > communicated via the
> > > > > > signal
> > > > > > > channel (which we don't have an agreement on it so far),
> > > > > > > this is not
> > > > > > specific
> > > > > > > to the filter-control spec but the same reasoning would
> > > > > > > apply for all ACLs instructed by the DOTS client (not only
> > > > > > > those that are adjusted during
> > > > > > attack
> > > > > > > times).
> > > > > >
> > > > > > Other ACLs activated using data channel are not part of
> > > > > > mitigation request, so no need to convey their stats using the signal
> channel.
> > > > > >
> > > > > > -Tiru
> > > > > >
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy
> > > > > > > > Envoyé : jeudi 25 avril 2019 13:04 À : Jon Shallow;
> > > > > > > > 'kaname nishizuka'; BOUCADAIR Mohamed TGI/OLN;
> [email-masked] Objet :
> > > RE:
> > > > > > > > [Dots]
> > > > > > > > > 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 there,
> > > > > > > > >
> > > > > > > > > different ACLs is that the DOTS client can then
> > > > > > > > > determine what is being effective or
> > > > > > not.
> > > > > > > > However,
> > > > > > > > > if (signal) data is able to get from the DOTS server to
> > > > > > > > > the DOTS client,
> > > > > > > > then it
> > > > > > > > > is likely that the data channel will still be operable
> > > > > > > > > and can be used to
> > > > > > > > get
> > > > > > > > > these numbers so I still do not think that this should
> > > > > > > > > be over the signal channel.
> > > > > > > > >
> > > > > > > > > should be the total dropped - i.e. the sum of the ACls
> > > > > > > > > and what the DMS is otherwise doing as it refers to the
> > > > > > > > > mitigation
> > > request.
> > > > > > > >
> > > > > > > > If the DOTS server knows the traffic dropped by ACLs and
> > > > > > > > the traffic dropped by DMS, why can't it provide this
> > > > > > > > statistics separately instead of summing it.  If the
> > > > > > > > incoming link is saturated, data channel will not function
> > > > > > > > but signal channel (using UDP) will work and there is a
> > > > > > > > good possibility that one of the GET responses
> > > > > > > > > > From: Dots [mailto: [email-masked]] On Behalf
> > > > > > > > > > Of kaname nishizuka
> > > > > > > > > > Regarding with the issue, I'm not convinced of the
> > > > > > > > > > benefit to return the activated ACL statistics over signal-
> channel.
> > > > > > > > > >
> > > > > > > > > > The idea of this draft is based on this situation
> > > > > > > > > > (quoted from Jon's
> > > > > > > > > > comment):
> > > > > > > > > > (It is) very unreliable when the inbound pipe is
> > > > > > > > > > running
> > full.
> > > > > > > > > > If the pipe is not running full, then this information
> > > > > > > > > > can be obtained over the
> > > > > > > > data
> > > > > > > > > channel.
> > > > > > > > > >
> > > > > > > > > > ACL stats can be get over the data-channel. I don't
> > > > > > > > > > see any reason to reproduce the same function.
> > > > > > > > > >
> > > > > > > > > > Further more, I don't think the DOTS server should
> > > > > > > > > > notify that DOTS client with the change by including
> > > > > > > > > > the corresponding
> > > > > > > > > >     This specification does not require any
> > > > > > > > > > modification to the
> > > > > > efficacy
> > > > > > > > > > acl-* per mitigation request, which make the function
> > > > > > > > > > of the signal-filter-control
> > > > > > > > > simple enough.
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > > Kaname
> > > > > > > > > >
> > > > > > > > > > >> internet- [email-masked] Envoyé : mercredi 24
> > > > > > > > > > >> avril
> > > > > > > > > > >> 2019
> > > > > > > > > > >> 07:34 À
> > > > > > :
> > > > > > > > > > >> [email-masked] Cc : [email-masked] Objet :
> > > > > > > > > > >> [Dots] I-D
> > > > > > Action:
> > > > > > > > > > >> Denial-of-Service Open Threat Signaling (DOTS)
> > > > > > > > > > >> Signal
> > > Channel
> > > > > > > > > > >>     that DOTS clients can control their filtering
> > > > > > > > > > >> rules when an
> > > > > > attack
> > > > > > > > > > >>     mitigation is active.
> > > > > > > > > > >>
> > > > > > > > > > >>     Particularly, this extension allows a DOTS
> > > > > > > > > > >> client to activate or
> > > > > > > > de-
> > > > > > > > > > >>     by a DOTS client during an idle time by means
> > > > > > > > > > >> of the DOTS
> > > > data
> > > > > > > > > > >>     channel protocol.
> > > > > > > > > > >>
> > > > > > > > > > >>     Please update these statements within the
> > > > > > > > > > >> document with the
> > > > > > > RFC
> > > > > > > > > > >>     o  "This version of this YANG module is part of
> > > > > > > > > > >> RFC
> > XXXX;"
> > > > > > > > > > >>
> > > > > > > > > > >>     Please update these statements with the RFC
> > > > > > > > > > >> number to be assigned
> > > > > > > > > to
> > > > > > > > > > >>     the following documents:
> > > > > > > > > > >>
> > > > > > > > > > >>     o  "RFC SSSS: Distributed Denial-of-Service
> > > > > > > > > > >> Open Threat
> > > > > > Signaling
> > > > > > > > > > >>     o  "RFC DDDD: Distributed Denial-of-Service
> > > > > > > > > > >> Open Threat
> > > > > > Signaling
> > > > > > > > > > >> Please note that it may take a couple of minutes
> > > > > > > > > > >> from the time of
> > > > > > > > > > submission
> > > > > > > > > > >> until the htmlized version and diff are available
> > > > > > > > > > >> at
> > > > > > tools.ietf.org.
> > > > > > > > > > >>

---

From: <[email-masked]>
Date: Mon, 29 Apr 2019 06:36:43 +0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 26 avril 2019 16:01

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

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

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 29 Apr 2019 08:52:02 +0000

> Sent: Monday, April 29, 2019 12:07 PM
> > > > Envoyé : vendredi 26 avril 2019 14:20 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Jon Shallow; 'kaname nishizuka'; [email-masked] Objet :
> > > > RE: [Dots]
> > > > > 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?
> >
> [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.

Based on statistics like the amount of attack traffic dropped by DMS, legitimate traffic received (after scrubbing), amount of traffic rate-limited, the client can infer the possible amount of good traffic rate-limited.

> > > > > local available information AND/OR status/aggregate stats
> > > > > received via the signal channel without relying on ACL-specific
> > > > > stats received from the
> > > > server.
> > > >
> > 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.

As I have previously mentioned, the rate-limit ACL is different from other ACL types, and hence the need of this functionality.
Conveying ACL-related stats for all other ACL types in the response packet over UDP would possibility exceed the path MTU, that's one of the reasons to restrict the functionality to only rate-limit ACL 
(or ACL activated using mitigation request). 

> 
> For example, a rate limit ACL can be programmed to be automatically
> enabled during mitigation (data channel) or explicitly using the signal channel.

I don’t think target networks would typically enable rate-limit ACL to be automatically enabled during mitigation, it means the target network is ready to lose business just because it was subjected to DDoS attack and even if the mitigation provider is capable of handling the attack, and your proposed scenario looks less likely. 

> Why the stats can only be shared for this ACL in the second case and not for
> the first case?
> 
> >
> > >
> > > > picture of the traffic rate-limited, bad traffic dropped by the
> > > > DDoS mitigation system, and using these stats the DOTS client can
> > > [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.

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.

Cheers
-Tiru

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

---

From: <[email-masked]>
Date: Mon, 29 Apr 2019 09:16:12 +0000

(Focusing on this particular point).

> Envoyé : lundi 29 avril 2019 10:52

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 29 Apr 2019 09:22:06 +0000

> From: [email-masked] <[email-masked]>
> Sent: Monday, April 29, 2019 2:46 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Jon Shallow <[email-masked]>; 'kaname nishizuka'
> <[email-masked]>; [email-masked]
> 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.
> 
> > > > > > 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.
> > > > >
> > > > > policies. It can select the appropriate ACL to
> > > > > activate/deactivate based on local experience.
> > > >
> > > [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
> > 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.

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 29 Apr 2019 10:40:33 +0100

Hi,

See inline,

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
> Sent: 29 April 2019 10:22
> To: [email-masked]; Jon Shallow; 'kaname nishizuka';
> [email-masked]
> <[email-masked]>;
> open

Is this correct?

> I am not referring to "nominal" services or critical resources. For instance,
> consider Netflix is not accessible to a large number

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)

~jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 29 Apr 2019 10:18:05 +0000

> From: Jon Shallow <[email-masked]>
> Sent: Monday, April 29, 2019 3:11 PM
> [email-masked]; kaname nishizuka <[email-masked]>;
> [email-masked]
> > > links or
> > > > Envoyé : lundi 29 avril 2019 10:52 À : BOUCADAIR Mohamed TGI/OLN;
> > > > > > > > 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.
> > > > > > >
> > > > > > > A DOTS client can preinstall the same rate-limit filter with
> > > > > > > but with
> > > > > > different
> > > > > > I don't get how the local experience will help the client pick
> > > > > > an alternate mitigation provider who can handle the attack scale.
> > > > >
> > > > > availability of services such as VoIP, IPTV, etc. The DOTS
> > > > > client can be fed with input
> > > > from
> > > [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.
> 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

---

From: <[email-masked]>
Date: Mon, 29 Apr 2019 11:34:43 +0000

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. 

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

Cheers,
Med

> Envoyé : lundi 29 avril 2019 12:18
> À : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [email-masked]
> 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
> > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 29 Apr 2019 12:46:35 +0000

> Sent: Monday, April 29, 2019 5:05 PM
> [email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
> (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

> > À : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; kaname nishizuka;
> > > > > click links or
> > > > > attachments unless you recognize the sender and know the content
> > > > > is
> > > safe.
> > > > >
> > > > > > Envoyé : lundi 29 avril 2019 10:52 À : BOUCADAIR Mohamed
> > > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > I don't get how the local experience will help the client
> > > > > > > > pick an alternate mitigation provider who can handle the attack
> scale.
> > > > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > I am not referring to "nominal" services or critical resources.
> > > > For instance, consider Netflix is not accessible to a large number
> > > 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
> > > 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

---

From: <[email-masked]>
Date: Mon, 29 Apr 2019 12:56:52 +0000

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. 

Cheers,
Med

> Envoyé : lundi 29 avril 2019 14:47
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; kaname nishizuka; [email-masked]
> "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
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 29 Apr 2019 12:58:40 +0000

> Sent: Monday, April 29, 2019 6:27 PM
> Looks like a candidate item in a separate DOTS telemetry specification I-D,
> rather than restricting it to the filter control case.
> 

Yes, works for me.

-Tiru

> > À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; kaname nishizuka;
> > > (1) a client domain with is basically "consuming" services. I do
> > > still
> > think this
> > > (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
> > >
> > > > Envoyé : lundi 29 avril 2019 12:18 À : Jon Shallow; BOUCADAIR
> > > > Mohamed TGI/OLN; kaname nishizuka; [email-masked] Objet : RE:
> > > > [Dots]
> > > > > > To: [email-masked]; Jon Shallow; 'kaname
> > > > > > nishizuka'; [email-masked]
> > > > > > > not click links or
> > > > > > > attachments unless you recognize the sender and know the
> > > > > > > content is
> > > > > safe.
> > > > > > >
> > > > > > > > > > > > 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
> > > > > > > > > > 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
> > > > > > > > legitimate traffic (or infer the number of users) unable
> > > > > > > > to use its service because of the rate- limit action.
> > > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > 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
> > > > > need their own limiting (black or rate-limit) ACL set up over
> > > > > the data channel.  At
> > > > this
> > > > > 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
> > > > > >

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 30 Apr 2019 23:24:28 +0900

Hi,

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