Repository navigation
Media Types and Request ID #112
Description
The Content-type HTTP header in Section 1.5.2 and the content_type message element in section 3.3.1 list should be adjusted to align with the Message Structure of Section 3.3.2.
There are three content_type values:
- the original application/openc2-cmd+json;version=1.0 when the HTTP body is OpenC2-Command
- the original application/openc2-rsp+json;version=1.0 when the HTTP body is OpenC2-Response
- the new application/openc2+json;version=1.0 when the HTTP body is OpenC2-Message, which contains the content OpenC2-Command, OpenC2-Response, or OpenC2-Notification.
So both the old examples in annex B.1 and the current message examples with headers/body are valid, but when the HTTP body is an OpenC2-Message, the Content-type should be application/openc2+json;version=1.0 without the -cmd or -rsp.
I don't have an opinion on if we should document both the old bare content format and the new message format, or just the new.
As we discussed with regard to the MQTT correlation value, I suggest that the examples in Annex B.1 include an HTTP X-Request-ID header with the same value as the Message "request_id" header. This ensures that standard web applications that know nothing about OpenC2 can still correlate requests and responses.
Producers SHOULD populate both the HTTP header and the Message header. (The SHOULD allows them to omit the Message request_id field if bandwidth is an issue and consumers are able to handle HTTP headers.)
Consumers MUST insert a copy of the HTTP X-Request-ID header into the Message header if present and the received Message does not contain a request_id field.
Activity
dlemire60 commentedon Jul 27, 2021
I'd like some rationale on this part of the issue:
Why should "standard web applications that know nothing about OpenC2" need to correlate requests and responses? Shouldn't they just ignore that traffic? I'd like to understand the value this would provide.
Also, it seems to me that allowing the producer to "omit the Message request_id field" is getting away from the OpenC2 message being an atomic item that can have integrity protection and source authentication from its message signature, and be bridge across multiple transfer protocols without issue. If anything, I'd conserve bandwidth by skipping the HTTP header, not modifying the message content.
davaya commentedon Jul 28, 2021
I'm thinking of network monitoring tools that provide a dashboard saying "1,592,432 outbound connections", etc. When the general practice of HTTP usage is to use the correlation header, the flow tracking/graphing tools don't have to know anything about HTTP bodies. Load balancers and crypto appliances might also use the information to route requests and responses along the same path. https://www.rapid7.com/blog/post/2016/12/23/the-value-of-correlation-ids/
The message integrity concern is valid, though if adding a duplicate header to the Message is a bandwidth concern, adding a signature would be worse.
The rules should allow tuning to the environment, and should specify what to do to allow interoperability in corner cases as well as normal ones. The corner cases may rarely be exercised, but they shouldn't break OpenC2 applications that didn't consider them. The default would be producers put correlation IDs in both places, then the workarounds are used only if the duplicate data breaks things.
dlemire60 commentedon Jul 28, 2021
I think we've generally agreed that OC2 over HTTPS isn't the first choice for a bandwidth-constrained scenario. Similarly, message source authentication and integrity is a priority, so expending bandwidth on that is probably unavoidable. So having a default that duplicates the message id into the HTTP correlation headers should be acceptable. I think the fallback should favor not breaking OpenC2 processing over relying on native protocol features, so should leave the OpenC2 message content unchanged. Also, I think the HTTPS case is different than the MQTT case: HTTP is natively point-to-point / request-response so copying the message ID into the correlation header doesn't alter behavior, whereas using the MQTT Response Topic feature when publishing a command actually switches the mode of operation from pub/sub to effectively point-to-point for that specific interaction, and I think that's a bad idea.
davaya commentedon Jul 28, 2021
I haven't done any looking into MQTT. My gut instinct from a position of ignorance is that if they designed a mechanism to handle request-response, they probably considered multiple responses from the same consumer and multiple responses from multiple consumers. I'd then specifically examine the spec and broker behavior to see if that assumption is wrong.
They might also have specifically said "this alters behavior so only one consumer can respond to any request". I'm not doubting that a custom approach is needed, just wondering.
dlemire60 commentedon Jul 28, 2021
The MQTT v5 description of the behavior is section 4.10. From my perspective, our default topic structure for MQTT addresses the need to get responses back to the producer and I prefer to avoid a parallel mechanism that's not interoperable with our design.
dlemire60 commentedon Sep 7, 2021
The content type aspects of this issue address in in PR #115, which also changed the message format to the atomic message format.
The correlation-id portion of this issue for HTTPS has not been addressed in a PR as of 9/8/2021.