Subject: Re: [Dots] clarification questions from the hackathon

From: <[email-masked]>
Date: Mon, 1 Apr 2019 07:04:24 +0000

Hi Kaname,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : kaname nishizuka [mailto:[email-masked]]
> Envoyé : vendredi 29 mars 2019 10:02
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; [email-masked]
> Objet : Re: [Dots] clarification questions from the hackathon
> 
> Hi,
> 
> please see inline.
> 
> regards,
> Kaname
> 
> On 2019/03/29 4:28, [email-masked] wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Jon Shallow [mailto:[email-masked]]
> >> Envoyé : jeudi 28 mars 2019 18:05
> >> À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [email-masked]
> >> Objet : RE: [Dots] clarification questions from the hackathon
> >>
> >> Hi All,
> >>
> >> See inline
> >>
> >> Regards
> >>
> >> Jon
> >>
> >>> -----Original Message-----
> >>> From: Dots [mailto: [email-masked]] On Behalf Of ietf-
> >>> [email-masked]
> >>> Sent: 28 March 2019 13:39
> >>> To: kaname nishizuka; [email-masked]
> >>> Subject: Re: [Dots] clarification questions from the hackathon
> >>>
> >>> Re-,
> >>>
> >>> Please see inline.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
> >>>> Envoyé : jeudi 28 mars 2019 11:38
> >>>> À : [email-masked]
> >>>> Objet : [Dots] clarification questions from the hackathon
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'd like to continue discussion of these topics in the ML.
> >>>>
> >>>> #1: Questions about signal-control-filtering
> >>>>    1. Should a mitigation request create a mitigation before doing a PUT
> +
> >>>> acl-list [{acl-name, activation-type}] against the active mitigation, or
> >> is a
> >>>> ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> >>>> mitigation?
> >>> [Med] Both are currently allowed in the draft. I don't still a valid
> reason
> >> to
> >>> restrict this.
> >> [Jon] As per draft
> >>     A DOTS client MUST NOT use the filtering control over DOTS signal
> >>     channel if no attack (mitigation) is active;
> >>
> > [Med] What is meant actually is:
> >
> >     A DOTS client MUST NOT use the filtering control over DOTS signal
> >     channel in 'idle' time;
> >
> > Will update the text.
> >
> [kaname]
> in order to make what I and Jon raised clearer,
> 
>     A DOTS client MUST NOT use the filtering control over DOTS signal
>     channel in 'idle' time.
>     If a mitigation request which includes both valid mitigation scope and
> acl-*
>     for the first time in idle time, it should be treated as it's already in
> attack time.
> 
> Or, simply I'm wondering if it is possible to drop the sentence because acl-*
> is always accompany with a mitigation scope so there is no way to enable it
> by itself in idle time?
> 

[Med] I prefer to leave the sentence because it was added to address a comment from Franck. He was concerned with the use of the feature when no attack is ongoing. That text does make that clear. 

I updated it as follows:

   A DOTS client MUST NOT use the filtering control over DOTS signal
   channel in 'idle' time; such requests MUST be discarded by the DOTS
   server with 4.00 (Bad Request).  By default, ACL-related operations
   are achieved using the DOTS data channel [I-D.ietf-dots-data-channel]
   when no attack is ongoing.

---

From: <[email-masked]>
Date: Mon, 1 Apr 2019 11:13:07 +0000

Jon, Kaname, all, 

FWIW, a proposal to integrate the interop comments is available at: 
https://github.com/boucadair/filter-control/blob/master/wdiff%20draft-nishizuka-dots-signal-control-filtering-05.txt%20draft-nishizuka-dots-signal-control-filtering-06.pdf 

Cheers,
Med

> > [Jon] then needs to be reworded as there is no active mitigation until the
> > PUT is done...
> > I believe that both cases should be supported.
> > >
> > > >   2. Should the response to a GET (or Observed GET) include the acl-
> list
> > > > [{acl-name, activation-type}] if the PUT included it?
> > >
> > > [Med] The current spec says "no". That's said, what would be the value in
> > > returning it? Then, why not allowing to return the references to all ACLs
> > that
> > > are enabled during the mitigation time?
> > >
> > [Jon] When observing the mitigation request, if the activation-type is
> > changed externally, the client will then know about the change. Assuming
> the
> > response got back to the client, this is effectively an ACK to the fact
> that
> > the ACL change got through.
> 
> [Med] The observe case makes sense, indeed.
> 
> >
> > Interesting concept about knowing about all the relevant ACLs as returned
> > over the signal channel.  More work for the server to do in determining
> which
> > ACLs are valid for, say, a specific IP address that is being mitigated.
> Not
> > entirely convinced of the benefit of this as this generally is available
> over
> > the data channel.
> >
> 
> [Med] I'm not convinced, either.
>

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 1 Apr 2019 12:26:44 +0100

Hi Med,

Changes look good to me - thanks.

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of 
[email-masked]
> Sent: 01 April 2019 12:13
> To: Jon Shallow; kaname nishizuka; [email-masked]
> https://github.com/boucadair/filter-control/blob/master/wdiff%20draft-
> nishizuka-dots-signal-control-filtering-05.txt%20draft-nishizuka-dots-signal-
> control-filtering-06.pdf
> 
> Cheers,
> Med
> 
> > > >
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 1 Apr 2019 13:30:42 +0000

Update looks good, couple of points to consider:

1> when the mitigation request is successfully applied, the response must include the acl-* attributes conveyed in the request (as per RFC7252 5.9.1.1). 
2> It looks useful to return the activated ACL statistics, for example If the client activates a rate-limit ACL, the ACL could be applied at the PE router 
(because the DMS is not capable of handling the attack volume). The rate-limit ACL will rate-limit both legitimate and attack traffic, and the DMS will scrub the rate-limited traffic and drop the attack traffic. The client may want to know the statistics of the traffic dropped because of the rate-limit ACL.

-Tiru

> From: Dots <[email-masked]> On Behalf Of
> Sent: Monday, April 1, 2019 4:43 PM
> To: 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.
> 
> Jon, Kaname, all,
> 
> > > > > De : Dots [mailto:[email-masked]] De la part de kaname
> > > > > nishizuka Envoyé : jeudi 28 mars 2019 11:38 À : [email-masked]
> > > > > acl-list [{acl-name, activation-type}] against the active
> > > > > mitigation,
> > or
> > > is a
> > > > > ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create
> > > > > a new mitigation?
> > > >
> > > [Jon] then needs to be reworded as there is no active mitigation
> > > until the PUT is done...
> > > > [Med] The current spec says "no". That's said, what would be the
> > > > value in returning it? Then, why not allowing to return the
> > > > references to all ACLs
> > > that
> > > [Jon] When observing the mitigation request, if the activation-type
> > > is changed externally, the client will then know about the change.
> > > Assuming
> > the
> > > Interesting concept about knowing about all the relevant ACLs as
> > > returned over the signal channel.  More work for the server to do in
> > > determining
> > which

---

From: <[email-masked]>
Date: Mon, 1 Apr 2019 14:01:47 +0000

Hi Tiru, 

Please see inline.

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : lundi 1 avril 2019 15:31
> À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; kaname nishizuka; [email-masked]
> 1> when the mitigation request is successfully applied, the response must
> include the acl-* attributes conveyed in the request (as per RFC7252
> 5.9.1.1).

[Med] I hesitated to add this one. What is the purpose of returning the acl-* in the response given that 2.01/2.04 are explicit that the type was successfully updated. Receiving a response such as the one in Figure 10 of the signal channel is straightforward. 

> 2> It looks useful to return the activated ACL statistics, for example If the
> client activates a rate-limit ACL, the ACL could be applied at the PE router
> (because the DMS is not capable of handling the attack volume). The rate-
> limit ACL will rate-limit both legitimate and attack traffic, and the DMS
> will scrub the rate-limited traffic and drop the attack traffic. The client
> may want to know the statistics of the traffic dropped because of the rate-
> limit ACL.

[Med] This one needs more discussion, IMO. I suggest to leave this one open for future revisions.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 1 Apr 2019 15:26:46 +0000

> From: [email-masked]
> <[email-masked]>
> Sent: Monday, April 1, 2019 7:32 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Jon Shallow <[email-masked]>; kaname nishizuka
> Subject: RE: [Dots] clarification questions from the hackathon
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; kaname nishizuka;
> > [email-masked] Objet : RE: [Dots] clarification questions from the
> > hackathon
> >
> > 1> when the mitigation request is successfully applied, the response
> > 1> must
> [Med] I hesitated to add this one. What is the purpose of returning the acl-*
> in the response given that 2.01/2.04 are explicit that the type was
> successfully updated. Receiving a response such as the one in Figure 10 of
> the signal channel is straightforward.

Yup.

> 
> > 2> It looks useful to return the activated ACL statistics, for example
> > 2> If the
> > client activates a rate-limit ACL, the ACL could be applied at the PE
> > router (because the DMS is not capable of handling the attack volume).
> > The rate- limit ACL will rate-limit both legitimate and attack
> > traffic, and the DMS will scrub the rate-limited traffic and drop the
> > attack traffic. The client may want to know the statistics of the
> > traffic dropped because of the rate- limit ACL.
> 

Sure, please add to github issues for tracking purpose.

-Tiru

> > > 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.
> > >
> > > Jon, Kaname, all,
> > >
> > > nishizuka-dots-signal-control-filtering-05.txt%20draft-nishizuka-dot
> > > s-
> > signal-
> > > control-filtering-06.pdf
> > >
> > > Cheers,
> > > Med
> > >
> > > > > >
> > > > > > > De : Dots [mailto:[email-masked]] De la part de
> > > > > > > kaname nishizuka Envoyé : jeudi 28 mars 2019 11:38 À :
> > > > > > > [email-masked] Objet : [Dots] clarification questions from
> > > > > > > the hackathon
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to
> > > > > > > create a new mitigation?
> > > > > >
> > > > > > >   2. Should the response to a GET (or Observed GET) include
> > > > > > > the
> > > > > > > acl-
> > > > list
> > > > > > [Med] The current spec says "no". That's said, what would be
> > > > > > the value in returning it? Then, why not allowing to return
> > > > > > the references to all ACLs
> > > > > that
> > > > > [Jon] When observing the mitigation request, if the
> > > > > activation-type is changed externally, the client will then know about
> the change.
> > > > > Assuming
> > > > the
> > > > > returned over the signal channel.  More work for the server to
> > > > > do in determining
> > > > which

---

From: <[email-masked]>
Date: Tue, 2 Apr 2019 05:14:54 +0000

Hi Tiru, 

I entered a new issue for the ACL stats: https://github.com/boucadair/filter-control/issues/1 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : lundi 1 avril 2019 17:27