Subject: [Dots] Feedback on draft-mortensen-threat-signaling-requirements-00

From: "Roman D. Danyliw" <[email-masked]>
Date: Sun, 19 Jul 2015 12:49:13 +0000

Hello Andrew!

Thanks again for producing this draft.  As an individual contributor, here are a few thoughts I had.

** The enumeration and definition of possible DOTS elements was helpful.

** Section 2.2: Configurational Channel 

-- The configuration channel is defined as being RESTful.  To everyone but Andrew, are there contrarian views on this?
-- What is meant by "local operator control" in the statement "The RESTful interface enables local operator control over DOTS elements."  Is the text suggesting control of all DOTS elements by a single operator?

** Section 2.4: Signal

-- Minor editorial note; the last sentence of this section is garbled.

** Section 2.5: Signal Response

-- IMO, I find the term "Signal Response" confusing given that the text states that the "... Signal Responses are sent without solicitation by a Signaler."

** Section 2.6: Signaler

-- If a "A Signaler MAY establish Signal Channels with multiple Signal Handler", can the Signaler request threat handling from multiple Signal Handlers?  Yes, right?

** Section 2.8: Signal Handler

-- "A Signal Handler may or may not be in the same domain as the Signaler."  IMO, the term "domain" in this context needs clarity.

** Section 3.1.1: Endpoint Communication

-- Are the suggestions made in this section referencing all of DOTS (i.e., configuration _and_ signaling channel) or just the signaling channel?  IMO, the text is best suited for only the signaling channel.

** Section 3.1.1.1: Signal Channel Health

"The protocol SHOULD include a way for each endpoint to detect when their respective peers last received a message."

-- The term end-point means one of the following: Signalers/Supplicants, Signal Handlers, Signal Relayers or Threat Handlers correct? 
-- I need help understanding what a peer is for each type of end-point.  With the statement "... [if] the endpoint SHOULD consider the peer unresponsive, ... [it should] in some way alert the operator to the loss of signal".  Which operator?

-- Is there anything more to signal channel health than tracking the last time you communicated with a peer?
 
Section 3.3.2: Signal Response

"the Signal Response SHOULD deliver feedback to the signaler from the entity or entities handling a threat on the signaler's behalf."

-- Is this statement implying that a Signal Response could come directly from a Threat Handler to a Supplicant (instead of from the Signal Handler)? 

Section 4: Configuration Channel

-- The list provided in this sections reads like things configured exclusively on the Signal Handler.  Do we need to configure anything on the Signaler?

Regards,
Roman

---

From: Andrew Mortensen <[email-masked]>
Date: Sun, 19 Jul 2015 22:31:18 -0400

Hi Roman. Thanks for taking the time to comment. I appreciate it.

I’ve responded inline below.

> On Jul 19, 2015, at 8:49 AM, Roman D. Danyliw <[email-masked]> wrote:
> <snip>
> <snip>

What I was trying to evoke here was the requirement (in my view) that operators of the signaling element should maintain control over the scope and triggers of threat handling for network space they own. That obviously didn’t come through. I’ll reword.

> -- Minor editorial note; the last sentence of this section is garbled.

Copy-pasta corrected, thanks.

> -- IMO, I find the term "Signal Response" confusing given that the text states that the "... Signal Responses are sent without solicitation by a Signaler.”

That should have been “…solicitation *from* a Signaler”, but I agree, the term isn’t ideal. I’ve had an offline suggestion that “Client Beacon” and “Server Beacon” would help make the distinction and the behavior clearer. I’m open to additional suggestions as well.

> -- If a "A Signaler MAY establish Signal Channels with multiple Signal Handler", can the Signaler request threat handling from multiple Signal Handlers?  Yes, right?

Yes. I’ll make that explicit.

> -- "A Signal Handler may or may not be in the same domain as the Signaler."  IMO, the term "domain" in this context needs clarity.

Will clarify.

> -- Are the suggestions made in this section referencing all of DOTS (i.e., configuration _and_ signaling channel) or just the signaling channel?  IMO, the text is best suited for only the signaling…

Agreed, the text in this draft is entirely focused on the signaling channel. As my suggestion of a RESTful interface suggests, I’ve been assuming the configuration channel will use https. I’ll make that clear.

> -- The term end-point means one of the following: Signalers/Supplicants, Signal Handlers, Signal Relayers or Threat Handlers correct?

Correct, except that I did not intend to imply Threat Handlers should communicate directly with a Signaler unless the Threat Handler is also a Signal Handler.

> -- I need help understanding what a peer is for each type of end-point.

As I had conceived of it, there are only the two types of endpoints for signaling, the Signaler and the Signal Handler, meaning the peer for a Signaler is a Signaler Handler, and vice versa.

> With the statement "... [if] the endpoint SHOULD consider the peer unresponsive, ... [it should] in some way alert the operator to the loss of signal".  Which operator?

The operator of the endpoint detecting signal degradation. In practice, both endpoints should notice the problem around the same time if they’ve agreed on a signal TTL. For example, if the Signal Handler continues to receiving messages from the Signaler, but the message indicates the Signaler hasn’t received anything from the Signal Handler for longer than the TTL, both endpoints should notice and alert their local operators.

> -- Is there anything more to signal channel health than tracking the last time you communicated with a peer?

Some metric communicating e.g. not only the presence of message loss but also the quantity would be useful. I’m concerned about trying to pack too much metadata in the signal, so I’m hoping feedback from the WG and further discussions about the protocol will help refine this.

> -- Is this statement implying that a Signal Response could come directly from a Threat Handler to a Supplicant (instead of from the Signal Handler)?

It is, but it shouldn’t be unless the Threat Handler and Signal Handler are synonymous in the deployment. Thanks for pointing it out. All communication should be between Signaler and Signal Handler.

> -- The list provided in this sections reads like things configured exclusively on the Signal Handler.  Do we need to configure anything on the Signaler?

The list does mention the Signaler Handler will be able to specify the unique identifier the Signaler will use in the signal, but yes, this section is far from comprehensive. Nik’s draft includes things like the address of the IPFIX collector (in my terminology, the Signal Handler), and I neglected that here.

andrew