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

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

Hi Med,

Please see inline

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Friday, January 18, 2019 1:47 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.
> 
> Re-,
> 
> See inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:[e-mail]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : vendredi 18 janvier 2019 08:48 À :
> > BOUCADAIR Mohamed TGI/OLN; Takahiko Nagata; [e-mail] Objet : Re:
> > [Dots] Comments on dots-signal-control-filtering-01
> >
> > > -----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.
> 
> [Med] If there is a risk of inconsistent configuration, it won't be specific to this
> case but a generic one.

It's not a generic scenario, the inconsistent configuration is be because two protocols are allowed to alter the ACL at the same time.

> 
> > Why use two protocols to do the same job ?
> 
> [Med] Because:
> * the functionality is there and its use will be for free.
> * the server checks are simplified. No need to do extra checks based on
> "trigger-mitigation"
> * the client may not subscribe to notification. Please note that we don't have a
> MUST, but a SHOULD.

Without the notification from the server, How will the client know the ACL needs to be altered ?
If the client detects the white-listed traffic is attacking the target by itself, it can use DOTS data channel protocol to alter the ACL. 
https://tools.ietf.org/html/draft-nishizuka-dots-signal-control-filtering-01#section-1.1 only discusses the scenario where it is useful to alter the ACL using signal channel during attack time, 
Please provide an attack scenario where allowing this alternation using signal channel is useful during peace time.

Cheers
-Tiru

> 
> >
> > -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
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots