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

From: "Jon Shallow" <[email-masked]>
Date: Thu, 28 Mar 2019 17:05:27 -0000

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;

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

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.

> >   3. Does the response to the PUT (the echoed back response payload of the
> > PUT representation https://tools.ietf.org/html/rfc7252#section-5.9.1.1 )
> > include the acl-list (if defined) or not?
> 
> [Med] It doesn't as we don't change the behavior of the base spec.
> 
[Jon] By base spec I assume you mean the signal draft.  However the answer has to be "yes - it is included" if following RFC7252 5.9.1.1 and "The payload returned with the response, if any, is a representation of the action result".  

Again, it is letting the client know that the PUT actually did get through (assuming the response gets through) prior to doing any GETs.
~jon

> >   4. Is the activation change to the ACL a permanent change to the ACL (so a
> > GET on the data channel returns the new type)?
> 
> [Med] Yes. The draft will be updated to make this clearer.
> 
> >   5. Does the activation change to the ACL count as an ACL refresh (pending-
> > lifetime update)?
> 
> [Med] Yes. Some text will be added to clarify the refresh point. That's said, as
> discussed in the data-channel, the dots client may need to send a GET after
> an attack for sync purposes.
> 
> >   6. Is CBOR activation –type comprehension-required or comprehension-
> > optional?
> >
> 
> [Med] This is a comprehension-required attribute (already discussed in the
> draft).
> 
> > Regarding with the 1st point, we got feedbacks from Med and Tiru that both
> > should be allowed.
> > If ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> > mitigation, it should be treated as this is a request in "attack-time".
> 
> [Med] I confirm.
> 
> >
> > (#2: Data Channel Implicit protocol number was addressed clearly by Med's
> > comment.)
> >
> > #3: (D)TLS session lifetime
> >  From the view point of DOTS server, when to expire the old (D)TLS session
> is
> > implementation specific though, I'd like to hear from experts about
> > preferable setting (timer or something else...?)
> >
> 
> [Med] For me, this is implementation-specific.
> 
> > thanks,
> 
> [Med] Many thanks for sharing the feedback from the hackathon. Much
> appreciated.
> 
> > Kaname
> >
> > _______________________________________________
> > Dots mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 28 Mar 2019 17:39:00 +0000

> From: Dots <[email-masked]> On Behalf Of Jon Shallow
> Sent: Thursday, March 28, 2019 6:05 PM
> To: [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.
> 
> Hi All,
> 
> See inline
> 
> Regards
> 
> Jon
> 
> > > 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,
> > >
> > >   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

Agreed.

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

Yup,  the GET response should include the acl-list. We will also have to discuss if the observed GET should convey the 
counters for the activated filtering rules using DOTS signal channel.

> 
> 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.
> 
> > >   3. Does the response to the PUT (the echoed back response payload
> > > of the PUT representation
> > > https://tools.ietf.org/html/rfc7252#section-5.9.1.1 ) include the acl-list (if
> defined) or not?
> >
> [Jon] By base spec I assume you mean the signal draft.  However the answer
> has to be "yes - it is included" if following RFC7252 5.9.1.1 and "The payload
> returned with the response, if any, is a representation of the action result".
> 
> Again, it is letting the client know that the PUT actually did get through
> (assuming the response gets through) prior to doing any GETs.

Yup, the PUT response should include the acl-list.

> ~jon
> 
> > >   4. Is the activation change to the ACL a permanent change to the
> > > ACL (so a GET on the data channel returns the new type)?
> >
> > >   5. Does the activation change to the ACL count as an ACL refresh
> > > (pending- lifetime update)?
> >
> > [Med] Yes. Some text will be added to clarify the refresh point.
> > That's said, as discussed in the data-channel, the dots client may
> > need to send a GET after an attack for sync purposes.

If the pending-lifetime expires when the mitigation is active, the DOTS server must not delete the aliases and filtering entries.
We may want to update DOTS data channel to clarify the above point.

Cheers,
-Tiru

> >
> > >   6. Is CBOR activation –type comprehension-required or
> > > comprehension- optional?
> > >
> >
> > [Med] This is a comprehension-required attribute (already discussed in
> > the draft).
> >
> > > Regarding with the 1st point, we got feedbacks from Med and Tiru
> > > that both should be allowed.
> > > If ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create
> > > a new mitigation, it should be treated as this is a request in "attack-time".
> >
> > [Med] I confirm.
> >
> > >

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 28 Mar 2019 17:58:07 -0000

Hi there,

See inline Jon1

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: 28 March 2019 17:39
> To: Jon Shallow; [email-masked]; kaname nishizuka;
> [email-masked]
> Yup,  the GET response should include the acl-list. We will also have to
> discuss if the observed GET should convey the

[Jon1] Interesting one - we already have bytes-dropped etc. as an overall return.  Whilst I like the concept of reporting the ACL acl-counters, with a reasonable number of ACLS, there is a good chance of having to split the response over multiple packets - which is supported (RFC7959 and tested during an Interop), but gets 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.

~Jon1
> If the pending-lifetime expires when the mitigation is active, the DOTS server
> must not delete the aliases and filtering entries.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 28 Mar 2019 18:07:04 +0000

> From: Jon Shallow <[email-masked]>
> Sent: Thursday, March 28, 2019 6:58 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; kaname nishizuka <[email-masked]>;
> [email-masked]
> Subject: RE: [Dots] clarification questions from the hackathon
> 
> > > > >   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}]’
> > > > [Med] Both are currently allowed in the draft. I don't still a
> > > > valid reason to restrict this.
> > >
> > > [Jon] As per draft
> > > > [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.
> >
> > Yup,  the GET response should include the acl-list. We will also have
> > to discuss if the observed GET should convey the counters for the
> > activated filtering rules using DOTS signal channel.
> 
> [Jon1] Interesting one - we already have bytes-dropped etc. as an overall
> return.  

The don't think bytes-dropped includes the overall bytes dropped. 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.

-Tiru

Whilst I like the concept of reporting the ACL acl-counters, with a
> reasonable number of ACLS, there is a good chance of having to split the
> response over multiple packets - which is supported (RFC7959 and tested
> during an Interop), but gets 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.
> 
> ~Jon1
> >
> > >
> > > 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.
> > >
> > > > >   3. Does the response to the PUT (the echoed back response
> > > > > payload of the PUT representation
> > > [Jon] By base spec I assume you mean the signal draft.  However the
> > > answer has to be "yes - it is included" if following RFC7252 5.9.1.1
> > > and "The payload returned with the response, if any, is a representation
> of the action result".
> > >
> > > Again, it is letting the client know that the PUT actually did get
> > > through (assuming the response gets through) prior to doing any GETs.
> >
> > > > >   4. Is the activation change to the ACL a permanent change to
> > > > > the ACL (so a GET on the data channel returns the new type)?
> > > >
> > If the pending-lifetime expires when the mitigation is active, the
> > DOTS server must not delete the aliases and filtering entries.
> > > > [Med] This is a comprehension-required attribute (already
> > > > discussed in the draft).
> > > >
> > > > > If ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to
> > > > > create a new mitigation, it should be treated as this is a
> > > > > request in "attack-
> > time".
> > > >
> > > > [Med] I confirm.
> > > >
> > > > >
> > > > > implementation specific though, I'd like to hear from experts
> > > > > about preferable setting (timer or something else...?)
> > > > >
> > > >
> > > > [Med] Many thanks for sharing the feedback from the hackathon.
> > > > Much appreciated.
> > > >
> > > > > Kaname
> > > > >

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 19:28:45 +0000

Re-,

Please see inline.

Cheers,
Med

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

[Med] What is meant actually is: 

   channel in 'idle' time;

Will update the text.

> 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

[Med] The observe case makes sense, indeed.

> 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: kaname nishizuka <[email-masked]>
Date: Fri, 29 Mar 2019 18:01:33 +0900

Hi,

please see inline.

regards,
Kaname

>     A DOTS client MUST NOT use the filtering control over DOTS signal
[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?