Re: [Dots] Comments on dots-signal-control-filtering-01

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

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, January 18, 2019 1:01 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Takahiko Nagata <[e-mail]>; [e-mail]
> Subject: RE: [Dots] Comments on dots-signal-control-filtering-01
> 
> 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.
> 
> Tiru,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[e-mail]]
> > Envoyé : vendredi 18 janvier 2019 08:14 À : BOUCADAIR Mohamed TGI/OLN;
> > Takahiko Nagata; [e-mail] Objet : RE: [Dots] Comments on
> > dots-signal-control-filtering-01
> >
> > > -----Original Message-----
> > > From: Dots <[e-mail]> On Behalf Of
> > > [e-mail]
> > > Sent: Friday, January 18, 2019 12:37 PM
> > > To: Takahiko Nagata <[e-mail]>; [e-mail]
> > > Subject: Re: [Dots] Comments on dots-signal-control-filtering-01
> > >
> > > 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 Takahiko,
> > >
> > > Thank you for sharing the comments.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Dots [mailto:[e-mail]] De la part de Takahiko
> > > > Nagata Envoyé : jeudi 17 janvier 2019 08:13 À : [e-mail]
> > > > Objet : [Dots] Comments on dots-signal-control-filtering-01
> > > >
> > > > Hi Kaname,
> > > >
> > > > I would like to 2 comments on dots-signal-control-filtering-01.
> > > >
> > > > (Comment1) Minimal attributes for control-filtering. ("lifetime"
> > behavior)
> > > >   Minimal attributes of SignalChannel MitigationRequest
> > > >   for control-filtering is only the followings, I think.
> > > >   - acl-list(acl-name, activation-type)
> > > >   - lifetime
> > > >
> > > >   So, We can send acl-list via SignalChannel without
> > > >   other Mitigation request parameters.
> > >
> > > [Med] When the same mid is used, the request is considered as a
> > > refresh. As such the attributes that were included in the first
> > > request must be
> > included.
> > >
> > > >
> > > >   In this case, we need to decide behavior of "lifetime".
> > > >   I think "lifetime" is ignored in this case.
> > >
> > > [Med] No. This is a particular case of this text from the signal
> > > channel
> > spec:
> > >
> > >    For a mitigation request to continue beyond the initial negotiated
> > >    lifetime, the DOTS client has to refresh the current mitigation
> > >    request by sending a new PUT request.  This PUT request MUST use the
> > >    same 'mid' value, and MUST repeat all the other parameters as sent in
> > >    the original mitigation request apart from a possible change to the
> > >    lifetime parameter value.
> > >
> > > >   Because acl-list(acl-name, activation-type) should be
> > > >   managed only DataChannel side for specification simply.
> > > >
> > > >
> > > > (Comment2) Should be specified behavior.
> > > > (a) Not be affected by "trigger-mitigation"
> > > >   acl-list(acl-name, activation-type) is soon be applied
> > > >   even if "trigger-mitigation" is false.
> > >
> > > [Med] The procedure applies independently of the value of "trigger-
> > mitigation".
> > > We can say this explicitly on the draft.
> >
> > A Mitigation request with "trigger-mitigation" set to false must only
> > be sent in the peace time and not during the attack time. During the
> > peace time, I don't see the need to activate/de-activate ACLs using
> > DOTS signal channel protocol.
> 
> [Med] The point is that the control functionality will be there. It is up to the
> client to decide to use:
> 
> * its data channel to alter the acl and then wait for a signal channel notification.
> These notifications may not be set by the client.
> * its signal channel to alter the acl.
> 
> With that approach we don't overload the server with extra validation on
> trigger-mitigation to decide about the behavior to follow.

This draft is introduced to alter the ACL using DOTS signal channel only during mitigation time because data channel does not work during attack time, and ACL alteration using DOTS signal channel  should not be allowed during peace time.
If allowed, the client can use both the DOTS data and signal channels to alter the ACL during peace time and can create inconsistent configuration. Why use two protocols to do the same job ?

-Tiru

> 
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > >
> > > > (b) Do not affect to "Efficacy Update"
> > > >   acl-list(acl-name, activation-type) would be ignored
> > > >   at "Efficacy Update" success or reject.
> > >
> > > [Med] Agree. We are not updating that part of the signal channel
> > > spec. acl-
> > list
> > > clauses won't be included in the efficacy update.
> > >
> > > >
> > > > (c) GET response of Mitigation Request
> > > >   acl-list(acl-name, activation-type) would not be included
> > > >   on respose of GET Mitigation Request.
> > >
> > > [Med] Yes. Will be make this clear in the draft.
> > >
> > > >
> > > > (d) In DELETE, no behavior(ex: rollback) for acl-list.
> > >
> > > [Med] Yes.
> > >
> > > >
> > > >
> > > > Best Regards,
> > > > Takahiko Nagata
> > > >
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots