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

From: Takahiko Nagata <[email-masked]>
Date: Thu, 17 Jan 2019 16:13:18 +0900

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.

  In this case, we need to decide behavior of "lifetime".
  I think "lifetime" is ignored in this case.
  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.

(b) Do not affect to "Efficacy Update"
  acl-list(acl-name, activation-type) would be ignored
  at "Efficacy Update" success or reject.

(c) GET response of Mitigation Request
  acl-list(acl-name, activation-type) would not be included
  on respose of GET Mitigation Request.

(d) In DELETE, no behavior(ex: rollback) for acl-list.

Best Regards,
Takahiko Nagata

---

From: <[email-masked]>
Date: Fri, 18 Jan 2019 07:07:14 +0000

Hi Takahiko, 

Thank you for sharing the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Takahiko Nagata
> Envoyé : jeudi 17 janvier 2019 08:13
> À : [email-masked]
> Objet : [Dots] Comments on dots-signal-control-filtering-01
> 
> Hi Kaname,
> 

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

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

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

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

>   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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 18 Jan 2019 07:13:58 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Friday, January 18, 2019 12:37 PM
> To: Takahiko Nagata <[email-masked]>; [email-masked]
> 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,
> 
> > Envoyé : jeudi 17 janvier 2019 08:13 À : [email-masked] Objet : [Dots]
> > Comments on dots-signal-control-filtering-01
> >
> > Hi Kaname,
> >
> [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.
> 
> >

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.

Cheers,
-Tiru

> [Med] Agree. We are not updating that part of the signal channel spec. acl-list
> clauses won't be included in the efficacy update.
> 
> >

---

From: <[email-masked]>
Date: Fri, 18 Jan 2019 07:31:23 +0000

Tiru, 

Please see inline.

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : vendredi 18 janvier 2019 08:14
> À : BOUCADAIR Mohamed TGI/OLN; Takahiko Nagata; [email-masked]
> Objet : RE: [Dots] Comments on dots-signal-control-filtering-01
> 
> > [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

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 18 Jan 2019 07:48:03 +0000

> From: [email-masked] <[email-masked]>
> Sent: Friday, January 18, 2019 1:01 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Takahiko Nagata <[email-masked]>; [email-masked]
> Subject: RE: [Dots] Comments on dots-signal-control-filtering-01
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > Envoyé : vendredi 18 janvier 2019 08:14 À : BOUCADAIR Mohamed TGI/OLN;
> > Takahiko Nagata; [email-masked] Objet : 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,
> > >
> > > > De : Dots [mailto:[email-masked]] De la part de Takahiko
> > > > Nagata Envoyé : jeudi 17 janvier 2019 08:13 À : [email-masked]
> > > [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.
> > >
> > > >
> > > [Med] No. This is a particular case of this text from the signal
> > > channel
> > spec:
> > >
> > 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.
> 
> * its data channel to alter the acl and then wait for a signal channel notification.
> These notifications may not be set by the client.
> 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

> > > [Med] Agree. We are not updating that part of the signal channel
> > > spec. acl-
> > list

---

From: <[email-masked]>
Date: Fri, 18 Jan 2019 08:17:03 +0000

Re-,

See inline. 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : vendredi 18 janvier 2019 08:48
> Objet : Re: [Dots] Comments on dots-signal-control-filtering-01
> 
> > [Med] The point is that the control functionality will be there. It is up
> to the
> > client to decide to use:
> >
> 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.

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 18 Jan 2019 13:53:49 +0000

Hi Med,

Please see inline

> Sent: Friday, January 18, 2019 1:47 PM
> > De : Dots [mailto:[email-masked]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : vendredi 18 janvier 2019 08:48 À :
> > BOUCADAIR Mohamed TGI/OLN; Takahiko Nagata; [email-masked] Objet : Re:
> > [Dots] Comments on dots-signal-control-filtering-01
> >
> > > > Envoyé : vendredi 18 janvier 2019 08:14 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Takahiko Nagata; [email-masked] Objet : RE: [Dots]
> > > > Comments on
> > > > > This email originated from outside of the organization. Do not
> > > > > click links
> > > > or
> > > > > > De : Dots [mailto:[email-masked]] De la part de
> > > > > > Takahiko Nagata Envoyé : jeudi 17 janvier 2019 08:13 À :
> > > > > > [email-masked] Objet : [Dots] Comments on
> > > > >    same 'mid' value, and MUST repeat all the other parameters as
> > > > > sent
> > in
> > > > 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.
> > >
> > > * its data channel to alter the acl and then wait for a signal
> > > channel
> > notification.
> > > 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.
> 

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

> * the client may not subscribe to notification. Please note that we don't have a

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

---

From: <[email-masked]>
Date: Fri, 18 Jan 2019 15:06:07 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 18 janvier 2019 14:54
> > [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. 

> > * the client may not subscribe to notification. Please note that we don't
> have a
> > MUST, but a SHOULD.
> 

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 21 Jan 2019 07:37:39 +0000

Hi Med,

Please see inline

> Sent: Friday, January 18, 2019 8:36 PM
> > Envoyé : vendredi 18 janvier 2019 14:54 À : BOUCADAIR Mohamed TGI/OLN;
> > > > > > A Mitigation request with "trigger-mitigation" set to false
> > > > > > must only be sent in the peace time and not during the attack time.
> > > > 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.
> > >
> > 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.
> 
> >
> > >
> > 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).
> 
> > 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.

You seem to missing the significant benefit, consider a scenario where the DOTS client uses different DOTS servers in the same domain for signal and data channel protocols.  These servers could be in different zones, and policy synchronization will not be instantaneous, and will take some time.  If the DOTS client uses the same server to alter the ACL during peace time, policy inconsistencies will not arise at all, and the DOTS server system only needs to share the state during attack time and reduces the operational concerns, and the delay incurred to respond to the client.

Cheers,
-Tiru

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