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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : vendredi 18 janvier 2019 14:54
> À : BOUCADAIR Mohamed TGI/OLN; Takahiko Nagata; [e-mail]
> Objet : RE: [Dots] Comments on dots-signal-control-filtering-01
> 
> Hi Med,
> 
> Please see inline
> 
> > > > >
> > > > > 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.

[Med] But this is what we are doing in dots-signal-control-filtering. It is true that when an attack is ongoing, the client will use the signal channel to control the ACL, still the object is controllable either by signal or data channels. 

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

[Med] this is covered by this part in the draft: 

   If not, the
   polling mechanism in Section 4.4.2.2 of
   [I-D.ietf-dots-signal-channel] has to be followed by the DOTS client.


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

[Med] Yes. That would be straightforward, but the client needs to get an update (either by notification or by polling the server).  

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

[Med] You seem to miss my point, Tiru. What I'm saying is that there isn't a significant benefit in asking the server to enforce validation checks based on the trigger-mitigation. If the server is able to get control when an attack is ongoing, it will be able to do so when for pre-configured requests, too. 

We may provide a guidance for the client to recommend dc for pre-configured requests, but we should not discard control message when they show up (either). 

> 
> Cheers
> -Tiru