[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: EXT :[openc2] Re: Request-response over pub/sub for openC2
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:
But that certainly doesn't eliminate the need for the spec to define where responses should be routed.
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
CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.
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 )
Happy to discuss further on the thread