OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[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


                In our experience, the channel for publishing commands are better served with action oriented topics. For example opendxl  topics are action oriented for commands. My draft on the specification is modelled on similar lines as of http(s), where we do not use the url to define action details, instead have the message specify the action details and parameters. From a standards perspective, I would advocate consistency between various transport specs, and potential have direct mappings from the constructs of one transport spec to other.

                Opendxl has limited support for wildcards. I am adding Chris Smith to the thread who can speak to opendxl authoritatively.





From: "Lemire, Dave (HII-TSD)" <david.lemire@hii-tsd.com>
Date: Tuesday, July 21, 2020 at 11:06 AM
To: "Das, Sudeep" <Sudeep_Das@McAfee.com>, "openc2@lists.oasis-open.org" <openc2@lists.oasis-open.org>
Subject: Re: EXT :[openc2] Re: Request-response over pub/sub for openC2


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




As I dive back into the MQTT spec, and look again at your message I think you've only answered part of Joe's original question.  The core of Joe's question was whether you'd recommend the channel(s) for publishing commands should be structured in an action-centric manner or a device-centric manner, based on McAfee's experience with pub/sub messaging. In your reply you focused on how responses would be routed back to the originating Producer, rather than the topic structure for sending commands. I looked at your OpenDXL transfer spec draft and that currently doesn't provide any guidance regarding command topic structure either, beyond starting with /oc2/{version}/


In a somewhat related question, does OpenDXL permit publishing wildcards, or is any individual message only published to a single topic (which could have many subscribers)?  I ask to compare / contrast with MQTT v3.1.1., where para of the v3.1.1 spec explicitly precludes wildcard characters in the PUBLISH packet topic.




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: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> on behalf of Das, Sudeep <Sudeep_Das@McAfee.com>
Sent: Monday, July 13, 2020 4:20:49 PM
To: duncan sfractal.com; openc2@lists.oasis-open.org
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.


More as a spec than an example, here is the McAfee opendxl messaging constructs for pub-sub and req-res


https://opendxl.github.io/opendxl-client-python/pydoc/dxlclient.message.html [opendxl.github.io]

If you look at the request message structure, it includes a field for the response topic.



From: "duncan sfractal.com" <duncan@sfractal.com>
Date: Saturday, July 4, 2020 at 6:02 AM
To: "Das, Sudeep" <Sudeep_Das@McAfee.com>, "openc2@lists.oasis-open.org" <openc2@lists.oasis-open.org>
Subject: Re: Request-response over pub/sub for openC2


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


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: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> on behalf of Das, Sudeep <Sudeep_Das@McAfee.com>
Sent: Friday, July 3, 2020 6:39:16 PM
To: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org>
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 )


  1. 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.
  2. The publisher embeds this response topic in the message so that the subscriber / actuator can publish the response back to the callback topic.
  3. 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]