Re: [Dots] clarification questions from the hackathon

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

> -----Original Message-----
> From: Jon Shallow <[e-mail]>
> Sent: Thursday, March 28, 2019 6:58 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> [e-mail]; kaname nishizuka <[e-mail]>;
> [e-mail]
> Subject: RE: [Dots] clarification questions from the hackathon
> 
> 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,
> 
> See inline Jon1
> 
> Regards
> 
> Jon
> 
> > -----Original Message-----
> > From: Dots [mailto: [e-mail]] On Behalf Of Konda,
> > Tirumaleswar Reddy
> > Sent: 28 March 2019 17:39
> > To: Jon Shallow; [e-mail]; kaname nishizuka;
> > [e-mail]
> > Subject: Re: [Dots] clarification questions from the hackathon
> >
> > > > > -----Message d'origine-----
> > > > > De : Dots [mailto:[e-mail]] De la part de kaname
> > > > > nishizuka Envoyé : jeudi 28 mars 2019 11:38 À : [e-mail]
> > > > > 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.
> >
> > 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.
> 
> [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
> > > > > 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.
> >
> > 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)?
> > > >
> > > > [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.
> >
> > 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.
> > > >
> > > > >
> > > > > (#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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/dots
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots