Re: EXT :[openc2] Re: Request-response over pub/sub for openC2

Sudeep,

Thanks for getting the discussion rolling on this.  

The in-development MQTT Transfer Specification includes a proposed default topic structure:  https://github.com/oasis-tcs/openc2-transf-mqtt/blob/working/transf-mqtt-v1.0.md#22-default-topic-structure.
 I would greatly appreciate your feedback on that proposal.

Regarding the request / response messaging construct, I like the concept of the Producer identifying the topic where the Consumer should publish its responses. I would note that the language does include command arguments for the Producer to indicate the
 desired level of response:  

The type of Response required for
 the Command: none, ack, status, complete

But that certainly doesn't eliminate the need for the spec to define where responses should be routed.

Dave

David Lemire

Systems Engineer

HII Mission Driven Innovated Solutions (HII-MDIS)

Technical Solutions Division

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190
 | Mobile (443) 535-1182

From:  <> on behalf of duncan sfractal.com <>

Sent: Saturday, July 4, 2020 9:02:01 AM

To: Das, Sudeep; 

Subject: EXT :[openc2] Re: Request-response over pub/sub for openC2

 

CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

Could you give an example? It would be particularly useful for a command (eg add a firewall rule, block an ip, etc) as the emphasis is on the C2 in openc2

iPhone, iTypo, iApologize

From:  <> on behalf of Das, Sudeep <>

Sent: Friday, July 3, 2020 6:39:16 PM

To:  <>

Subject: [openc2] Request-response over pub/sub for openC2

 

Openc2 members, 

                I received a request for technical assistance on openc2 over mqtt spec from Mr Brule earlier today. I am responding to oasis relay as recommended by Mr Brule.

 

The discussion is around setting up topics. 

 

> Would you set up a topic that is 'action' so an orchestrator would

> post a 'deny evil_domain' then would you set up another topic 'response_action'

> so any actuator that could act on the deny evil domain would post

> its ack on the 'response_deny' channel?    Or would you guys make the

>topics more device centric, so there would be a topic that is 'gateway_routers'

> and the orchestrator posts the commands there then each

> router would have its own topic 'router_one', 'router_two' etc. to post its response.  

 

There are a few challenges to the openc2 spec in terms of pub sub. Openc2 messaging specifies request-response semantics, which is a different message pattern vis-à-vis pub-sub. The way we may manage req-res over pub-sub is as below (as
 implemented in McAfee opendxl )

 

An orchestrator / publisher who intends to receive a response shall subscribe to a an arbitrary topic of its choice. We simply call this the response topic, and it is like the publishers
 callback phone number. Normally you want this callback topic to be statistically unique, and a guid works well.

The publisher embeds this response topic in the message so that the subscriber / actuator can publish the response back to the callback topic.

The actuator / subscriber topics are better named after the actions rather than the device.  Device characteristics are generally unbounded, and you see a topic sprawl with a device
 centric topic naming as compared to a capability centric topic naming. Also, capabilities centric naming has other benefits like creating a topic hierarchy that automatically describes a hierarchy of actions.

 

Happy to discuss further on the thread

 

Sudeep Das

Principal Engineer

McAfee LLC