Subject: [Dots] Some notes on reddy-dots-signal-channel

From: Dave Dolson <[email-masked]>
Date: Tue, 28 Mar 2017 17:47:58 +0000

A couple of high-level comments: See if we agree on these concepts:

-          I believe we want to remove the "Session" aspects of the protocol - heartbeat, ACK timeouts, etc. Yesterday at the design-team meeting I think there was rough agreement on this.

-          Policy-id doesn't identify a policy; it identifies an "event" or "transaction" or ?

-          We want loose coupling between signal and data channels, so I believe the "alias" does not need to be joined to data channel identifier, but could refer to any identifier by name. E.g., "Default" could indicate a canned mitigation strategy/policy.

-          It seems that mitigation requests should be created with POST, not PUT, because a new thing is being created vs. overwriting an existing thing. PUT could be used to update an existing event.

If there are no objections, I can help with these changes.

-Dave

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 29 Mar 2017 15:25:37 +0000

On Mar 28, 2017, at 1:47 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

-          I believe we want to remove the “Session” aspects of the protocol – heartbeat, ACK timeouts, etc. Yesterday at the design-team meeting I think there was rough agreement on this.

My impression was that there was rough agreement that the current use of “session” in the requirements draft is misleading, but I didn’t come away thinking we needed to remove heartbeats from the signal channel. Heartbeats are currently a requirement for channel health monitoring, and are a mitigation trigger (dead-man’s switch) discussed in the architecture draft. What’s your case for removing them?

-          Policy-id doesn’t identify a policy; it identifies an “event” or “transaction” or ?

Regardless of the term we settle on, I agree, policy-id is inaccurate.

-          We want loose coupling between signal and data channels, so I believe the “alias” does not need to be joined to data channel identifier, but could refer to any identifier by name. E.g., “Default” could indicate a canned mitigation strategy/policy.

Yes.

POST and PUT don’t map to create and update in CRUD. PUT can be used to create or to update. I prefer to use the one method.

andrew

---

From: Dave Dolson <[email-masked]>
Date: Wed, 29 Mar 2017 15:49:57 +0000

Regarding the session aspects, I’m glad I asked. I misunderstood. I thought people were saying there should only be communication when there is an attack.

From: Mortensen, Andrew [mailto:[email-masked]]
Sent: Wednesday, March 29, 2017 10:26 AM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [Dots] Some notes on reddy-dots-signal-channel

Yes.

andrew

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 30 Mar 2017 02:38:54 +0000

Hi Dave,

Thanks for the comments, Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, March 28, 2017 11:18 PM
To: [email-masked]
Subject: [Dots] Some notes on reddy-dots-signal-channel

[TR] I don't understand the above comment. what do you mean by "session aspects" of the protocol ?
(D)TLS session is bound to the host/port quartet, and heartbeats are required b/w DOTS peers to maintain the cryptographic context and to know if the DOTS peer is alive. Heartbeat timeout and other message transmission parameters can be negotiated b/w the DOTS peers.

[TR] policy-id uniquely identifies the mitigation request bound to the DOTS client.

[TR] I did not get the above comment, as per the requirements in https://tools.ietf.org/html/draft-ietf-dots-requirements-04 aliases can either be created using the DOTS data channel or direct configuration, and later used in the DOTS signal channel.

[TR] PUT method can be used to both create or over-write an existing thing (see https://tools.ietf.org/html/rfc7252#section-5.8.3) . The reason for using PUT is that mitigation request/response are marked as a non-confirmable messages and sent at regular intervals until a response is received from the DOTS server, and unlike POST, PUT is idempotent. For example, IOT devices for group communication use PUT instead of POST.

-Tiru

-Dave