Subject: [Dots] DOTS Requirements: DATA-003 Session configuration

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Sep 2016 12:39:31 -0400

Requirement DATA-003 (Session configuration), which deals with the data 
channel requirement, include the  following:
<quote>
DOTS server
       implementations MUST have mechanisms to configure the following:

       *  Acceptable signal lossiness, as described in GEN-002.

       *  Heartbeat intervals, as described in OP-002.

       *  Maximum mitigation lifetime, as described in OP-005.

       *  Resource identifiers, as described in OP-006.
</quote>

Resource identifier config makes sense to me, but why aren't the first 3 
simply part of the signal channel establishment procedure (which would 
have the added benefit of allowing them to be adjusted more easily later 
on) ?

Thanks

-- Flemming

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Mon, 26 Sep 2016 03:30:22 +0000

Thanks for the question. See inline below.

> On Sep 25, 2016, at 12:39 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> Requirement DATA-003 (Session configuration), which deals with the data channel requirement, include the  following:
> <quote>
> DOTS server
> Resource identifier config makes sense to me, but why aren't the first 3 simply part of the signal channel establishment procedure (which would have the added benefit of allowing them to be adjusted more easily later on) ?

I agree, the first three do seem like good parameters to include when establishing the signal channel. I had been thinking of them as global parameters affecting all signal channels established by the DOTS client.

In moving them to the signal channel we should also define how the server handles invalid values for any of the three. Should the server simply refuse to establish the session, or fall back to protocol-defined defaults?

andrew

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 26 Sep 2016 09:16:39 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Flemming Andreasen
> (fandreas)
> Sent: Sunday, September 25, 2016 10:10 PM
> To: dots <[email-masked]>
> Subject: [Dots] DOTS Requirements: DATA-003 Session configuration
> 
> Resource identifier config makes sense to me, but why aren't the first 3 simply
> part of the signal channel establishment procedure (which would have the
> added benefit of allowing them to be adjusted more easily later
> on) ?

Acceptable signal lossiness configuration helps determine the lossiness parameters (e.g. max number of re-transmissions, max re-transmission parameters etc.) for the first DOTS signal message. The first DOTS signal message may convey new signal lossiness configuration parameters for subsequent DOTS signal messages.

Heartbeat intervals and Maximum mitigation lifetime configuration in DOTS data channel can be treated as global configuration used for all DOTS signal channels b/w DOTS agents, unless specifically over-written by the DOTS signal channel.

-Tiru

> 
> Thanks
> 
> -- Flemming
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 26 Sep 2016 09:19:57 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
> Sent: Monday, September 26, 2016 9:00 AM
> To: Flemming Andreasen (fandreas) <[email-masked]>
> Cc: dots <[email-masked]>
> Subject: Re: [Dots] DOTS Requirements: DATA-003 Session configuration
> 
> simply part of the signal channel establishment procedure (which would have
> the added benefit of allowing them to be adjusted more easily later on) ?
> 
> I agree, the first three do seem like good parameters to include when
> establishing the signal channel. I had been thinking of them as global
> parameters affecting all signal channels established by the DOTS client.

I think it's useful to signal them in the DOTS data channel.

> 
> In moving them to the signal channel we should also define how the server
> handles invalid values for any of the three. Should the server simply refuse to
> establish the session, or fall back to protocol-defined defaults ?

Server should only refuse the configuration request but continue to establish the session and process other requests from the client and continue to use the default values.

-Tiru

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Sep 2016 14:11:42 -0400

> In moving them to the signal channel we should also define how the server handles invalid values for any of the three. Should the server simply refuse to establish the session, or fall back to prot…
Either that, or the server can pick the closests values it supports and 
tell the client about those. If the client doesn't like those, it can 
always end the session.

-- Flemming

> andrew.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Sep 2016 14:13:17 -0400

> Server should only refuse the configuration request but continue to establish the session and process other requests from the client and continue to use the default values.
I'm not sure what that means - do you assume there is a separate config 
requests here ?

Thanks

-- Flemming

> .

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Sep 2016 14:15:49 -0400

> Heartbeat intervals and Maximum mitigation lifetime configuration in DOTS data channel can be treated as global configuration used for all DOTS signal channels b/w DOTS agents, unless specifically…
Seems like more complexity than needed - I'd just have one set of values 
in the protocol (signal channel).

Thanks

-- Flemming

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Sep 2016 04:16:10 +0000

> From: Flemming Andreasen (fandreas)
> Sent: Monday, September 26, 2016 11:43 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; Mortensen, Andrew
> <[email-masked]>
> Cc: dots <[email-masked]>
> >>> On Sep 25, 2016, at 12:39 PM, Flemming Andreasen
> >>> <[email-masked]>
> >> wrote:
> >> simply part of the signal channel establishment procedure (which
> >> would have the added benefit of allowing them to be adjusted more easily
> later on) ?
> >>
> >> establishing the signal channel. I had been thinking of them as
> >> global parameters affecting all signal channels established by the DOTS
> client.
> >> In moving them to the signal channel we should also define how the
> >> server handles invalid values for any of the three. Should the server
> >> simply refuse to establish the session, or fall back to protocol-defined
> defaults ?
> > Server should only refuse the configuration request but continue to establish
> the session and process other requests from the client and continue to use the
> default values.

Yes, use separate requests for signaling possible DDoS attack and signal channel configuration to the DOTS server.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Sep 2016 04:24:22 +0000

> Sent: Monday, September 26, 2016 11:46 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; dots <[email-masked]>
> >> Requirement DATA-003 (Session configuration), which deals with the
> >> data channel requirement, include the  following:
> >> <quote>
> >> DOTS server
> >> Resource identifier config makes sense to me, but why aren't the
> >> first 3 simply part of the signal channel establishment procedure
> >> (which would have the added benefit of allowing them to be adjusted
> >> more easily later
> >> on) ?
> > Acceptable signal lossiness configuration helps determine the lossiness
> parameters (e.g. max number of re-transmissions, max re-transmission
> parameters etc.) for the first DOTS signal message. The first DOTS signal
> message may convey new signal lossiness configuration parameters for
> subsequent DOTS signal messages.
> >
> > Heartbeat intervals and Maximum mitigation lifetime configuration in DOTS
> data channel can be treated as global configuration used for all DOTS signal
> channels b/w DOTS agents, unless specifically over-written by the DOTS signal
> channel.
> Seems like more complexity than needed - I'd just have one set of values in
> the protocol (signal channel).

The advantage of the above approach is: setting the values in data channel during peace time avoids the need to convey the configuration parameters in the signal channel during DDoS attack.

-Tiru

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 27 Sep 2016 08:29:15 -0400

> The advantage of the above approach is: setting the values in data channel during peace time avoids the need to convey the configuration parameters in the signal channel during DDoS attack.
You have to establish a bidirectional mutually authenticated signal 
channel regardless, so at least one message needs to get through - that 
message can simply set the value.

As for having the same data conveyed via multiple avenues, it adds 
additional complexity and leads to various inconsistency and race 
condition issues you have to deal with. I'm not in favor of that unless 
it adds substantial benefits, and I haven't seen those yet.

Thanks

-- Flemming

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 27 Sep 2016 12:48:07 +0000

On 27/09/2016, 13:29, "Dots on behalf of Flemming Andreasen" <[email-masked] on behalf of [email-masked]> wrote:

I agree that this needs to be set via a single method and not be repeated, redundant or hierarchical in any way.  Spreading it across different channels just creates problems and what if’s.

Thanks,

-Nik

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Sep 2016 12:50:36 +0000

> Sent: Tuesday, September 27, 2016 5:59 PM
> >> parameters etc.) for the first DOTS signal message. The first DOTS
> >> signal message may convey new signal lossiness configuration
> >> parameters for subsequent DOTS signal messages.
> >> data channel can be treated as global configuration used for all DOTS
> >> signal channels b/w DOTS agents, unless specifically over-written by
> >> the DOTS signal channel.
> >> Seems like more complexity than needed - I'd just have one set of
> >> values in the protocol (signal channel).
> > The advantage of the above approach is: setting the values in data channel
> during peace time avoids the need to convey the configuration parameters in
> the signal channel during DDoS attack.
> You have to establish a bidirectional mutually authenticated signal channel
> regardless, so at least one message needs to get through - that message can
> simply set the value.

That one message can convey the DOTS signal, and over-loading this request with additional configuration parameters will increase the complexity of handling error conditions where the server may act on the DOTS signal but the configuration parameters may not be acceptable to the server.  The negotiation of the configuration may take multiple requests/responses and may involve multiple re-transmissions during a DDOS attack.

> 
> As for having the same data conveyed via multiple avenues, it adds additional
> complexity and leads to various inconsistency and race condition issues you
> have to deal with. I'm not in favor of that unless it adds substantial benefits,
> and I haven't seen those yet.

The advantage is DOTS data channel will anyway be created during the peacetime to create alias, it can also be used to negotiate configuration parameters and can be used for all the DOTS signal channels.

The message transmission parameters negotiated in DOTS data channel during peace time can be used influence the max number of retransmissions, max retransmission span etc. for first DOTS signal message.

I don't see a need to re-negotiate the configuration parameters in the DOTS signal channel during a DDOS attack.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 27 Sep 2016 09:55:50 -0400

I think we have different views of the DOTS world here. My view is that 
you start establishing a signal channel, and you may establish a data 
channel that occasionally can be used to convey various operationally 
related parameters, such as whitelists, blacklists, filters, etc. The 
signal channel should specify how the signal channel works as part of 
the signal channel establishment; that includes configuration 
parameters, extensions supported, etc.

No DOTS signal channel => no DOTS operation.
No DOTS data channel does not necessarily imply the same.

As to arguments around the data channel being the better place to 
negotiate things because it's used during peace-time, it's a red herring 
because the signal channel will obviously work just as well in 
peace-time. Now, I agree, we should'n't renegotiate the parameters in 
question during an attack, but again, it's orthogonal to whether that is 
done in the signal or data channel - if anything, the data channel would 
have a much lower chance of working during an active DDoS attack.

Thanks

-- Flemming

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Sep 2016 14:15:59 +0000

> Sent: Tuesday, September 27, 2016 7:26 PM
> I think we have different views of the DOTS world here. My view is that you
> start establishing a signal channel, and you may establish a data channel that
> occasionally can be used to convey various operationally related parameters,
> such as whitelists, blacklists, filters, etc. 

In various scenarios, DOTS data channel is supposed to be established before DOTS signal channel, for example to create alias for resources. 

> The signal channel should specify how
> the signal channel works as part of the signal channel establishment; that
> includes configuration parameters, extensions supported, etc.
> 
> As to arguments around the data channel being the better place to negotiate
> things because it's used during peace-time, it's a red herring because the
> signal channel will obviously work just as well in peace-time. Now, I agree, we
> should'n't renegotiate the parameters in question during an attack, but again,
> it's orthogonal to whether that is done in the signal or data channel - if
> anything, the data channel would have a much lower chance of working
> during an active DDoS attack.

Yes, DOTS data channel is expected to be used only during peacetime. 
If we agree that configuration parameters should be negotiated during peacetime then using DOTS signal channel to negotiate them works for me.

-Tiru

> >>>>>> Requirement DATA-003 (Session configuration), which deals with
> >>>>>> the data channel requirement, include the  following:
> >>>>>> <quote>
> >>>>>> DOTS server
> >>>>>> (which would have the added benefit of allowing them to be
> >>>>>> adjusted more easily later
> >>>>>> on) ?
> >>>> parameters (e.g. max number of re-transmissions, max
> >>>> re-transmission parameters etc.) for the first DOTS signal message.
> >>>> The first DOTS signal message may convey new signal lossiness
> >>>> configuration parameters for subsequent DOTS signal messages.
> >>>> data channel can be treated as global configuration used for all
> >>>> DOTS signal channels b/w DOTS agents, unless specifically
> >>>> over-written by the DOTS signal channel.
> >> during peace time avoids the need to convey the configuration
> >> parameters in the signal channel during DDoS attack.
> >> channel regardless, so at least one message needs to get through -
> >> that message can simply set the value.
> > That one message can convey the DOTS signal, and over-loading this request
> with additional configuration parameters will increase the complexity of
> handling error conditions where the server may act on the DOTS signal but the
> configuration parameters may not be acceptable to the server.  The
> negotiation of the configuration may take multiple requests/responses and
> may involve multiple re-transmissions during a DDOS attack.
> >
> >> condition issues you have to deal with. I'm not in favor of that
> >> unless it adds substantial benefits, and I haven't seen those yet.
> > The advantage is DOTS data channel will anyway be created during the
> peacetime to create alias, it can also be used to negotiate configuration
> parameters and can be used for all the DOTS signal channels.
> >
> > The message transmission parameters negotiated in DOTS data channel
> during peace time can be used influence the max number of retransmissions,
> max retransmission span etc. for first DOTS signal message.
> >

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 28 Sep 2016 00:30:05 +0000

Hi,

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Tirumaleswar Reddy (tireddy)
发送时间: 2016年9月27日 22:16
收件人: Flemming Andreasen (fandreas); dots
主题: Re: [Dots] DOTS Requirements: DATA-003 Session configuration

> I think we have different views of the DOTS world here. My view is 
> that you start establishing a signal channel, and you may establish a 
> data channel that occasionally can be used to convey various 
> operationally related parameters, such as whitelists, blacklists, filters, etc.

In various scenarios, DOTS data channel is supposed to be established before DOTS signal channel, for example to create alias for resources. 
[Frank]: the point is some configuration parameters had better be exchanged during the peacetime, usually before the signaling channel is established. Using data channel for this function is reasonable and logically clear for me.

> the signal channel works as part of the signal channel establishment; 
> that includes configuration parameters, extensions supported, etc.
> 
> negotiate things because it's used during peace-time, it's a red 
> herring because the signal channel will obviously work just as well in 
> question during an attack, but again, it's orthogonal to whether that 
> is done in the signal or data channel - if anything, the data channel 
> would have a much lower chance of working during an active DDoS attack.

Yes, DOTS data channel is expected to be used only during peacetime. 
If we agree that configuration parameters should be negotiated during peacetime then using DOTS signal channel to negotiate them works for me.
[Frank]: disagree, it is not necessary and will influence the existing DOTS architecture.

B.R.
Frank

-Tiru

> >>>>>> Resource identifier config makes sense to me, but why aren't 
> >>>>>> the first 3 simply part of the signal channel establishment 
> >>>>>> procedure (which would have the added benefit of allowing them 
> >>>>>> to be adjusted more easily later
> >>>>>> on) ?
> with additional configuration parameters will increase the complexity 
> of handling error conditions where the server may act on the DOTS 
> signal but the configuration parameters may not be acceptable to the 
> server.  The negotiation of the configuration may take multiple 
> requests/responses and may involve multiple re-transmissions during a DDOS attack.
> >
> peacetime to create alias, it can also be used to negotiate 
> configuration parameters and can be used for all the DOTS signal channels.
> >
> during peace time can be used influence the max number of 
> retransmissions, max retransmission span etc. for first DOTS signal message.
> >
> > I don't see a need to re-negotiate the configuration parameters in 
> > the DOTS
> signal channel during a DDOS attack.
> >
> >> Thanks
> >>
> >> -- Flemming
> > .
> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 29 Sep 2016 02:36:48 +0000

> From: Xialiang (Frank) [mailto:[email-masked]]
> Sent: Wednesday, September 28, 2016 6:00 AM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; Flemming Andreasen
> (fandreas) <[email-masked]>; dots <[email-masked]>
> Subject: 答复: [Dots] DOTS Requirements: DATA-003 Session configuration
> 
> Hi,
> 
> -----邮件原件-----
> In various scenarios, DOTS data channel is supposed to be established before
> DOTS signal channel, for example to create alias for resources.
> [Frank]: the point is some configuration parameters had better be exchanged
> during the peacetime, usually before the signaling channel is established.
> Using data channel for this function is reasonable and logically clear for me.
> 
> If we agree that configuration parameters should be negotiated during
> peacetime then using DOTS signal channel to negotiate them works for me.

DOTS data channel will still be used for other configuration like filters, alias etc. The reason for moving these configuration parameters are that the DOTS signal channel may want to later update it based on the network conditions and it's better to negotiate them in one channel and not multiple channels. 

Why do you think it is not necessary and will impact the DOTS architecture adversely ?

-Tiru

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 29 Sep 2016 03:02:26 +0000

Hi Tiru,

-----邮件原件-----
发件人: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
发送时间: 2016年9月29日 10:37
收件人: Xialiang (Frank); Flemming Andreasen (fandreas); dots
主题: RE: [Dots] DOTS Requirements: DATA-003 Session configuration

> > that you start establishing a signal channel, and you may establish 
> > a data channel that occasionally can be used to convey various 
> In various scenarios, DOTS data channel is supposed to be established 
> before DOTS signal channel, for example to create alias for resources.
> [Frank]: the point is some configuration parameters had better be 
> exchanged during the peacetime, usually before the signaling channel is established.
> > The signal channel should specify how the signal channel works as 
> > part of the signal channel establishment; that includes 
> > configuration parameters, extensions supported, etc.
> >
> > herring because the signal channel will obviously work just as well 
> > in peace-time. Now, I agree, we should'n't renegotiate the 
> > parameters in question during an attack, but again, it's orthogonal 
> > to whether that is done in the signal or data channel - if anything, 
> > the data channel would have a much lower chance of working during an active DDoS attack.
> 

DOTS data channel will still be used for other configuration like filters, alias etc. The reason for moving these configuration parameters are that the DOTS signal channel may want to later update it based on the network conditions and it's better to negotiate them in one channel and not multiple channels. 
[Frank]: DOTS signaling channel had better be used to send messages of call for help, status update, essential telemetry. Sending configuration parameters of signaling channel by itself seems a little bit tricky, IMHO.

B.R.
Frank

-Tiru

> > >>>>>> Requirement DATA-003 (Session configuration), which deals 
> > >>>>>> with the data channel requirement, include the  following:
> > >>>>>> <quote>
> > >>>>>> DOTS server
> > >>>>>>           implementations MUST have mechanisms to configure 
> > >>>>>> the
> > >> following:
> > >>>>>> procedure (which would have the added benefit of allowing 
> > >>>>>> them to be adjusted more easily later
> > >>>>>> on) ?
> > >>>> data channel can be treated as global configuration used for 
> > >>>> all DOTS signal channels b/w DOTS agents, unless specifically 
> > >>>> Seems like more complexity than needed - I'd just have one set 
> > >>>> of values in the protocol (signal channel).
> > >> You have to establish a bidirectional mutually authenticated 
> > >> signal channel regardless, so at least one message needs to get 
> > >> through - that message can simply set the value.
> > with additional configuration parameters will increase the 
> > complexity of handling error conditions where the server may act on 
> > the DOTS signal but the configuration parameters may not be 
> > acceptable to the server.  The negotiation of the configuration may 
> > take multiple requests/responses and may involve multiple 
> > re-transmissions during a
> DDOS attack.
> > >
> > >> As for having the same data conveyed via multiple avenues, it 
> > >> adds additional complexity and leads to various inconsistency and 
> > >> race condition issues you have to deal with. I'm not in favor of 
> > >> that unless it adds substantial benefits, and I haven't seen those yet.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 29 Sep 2016 10:36:37 -0400

> [Frank]: DOTS signaling channel had better be used to send messages of call for help, status update, essential telemetry. Sending configuration parameters of signaling channel by itself seems a lit…

Can you elaborate on what makes it tricky ? My view is that spreading 
these parameters over two different channels (signal and data) is more 
tricky than simply conveying them as part of the signal channel itself 
(different contexts, no fate sharing, etc. which are all handled 
trivially when using a single channel).

Thanks

-- Flemming