Handling Response = None

[dlemire60]

There is a conflict between the OpenC2 language concept of controlling the level of response, and the HTTP norm of always requiring a response. The HTTPS specification needs to clarify the proper way to handle the OpenC2 "response = none" case.

This is issue number 8 from the January 2020 Plug Fest / Hackathon

[jmbrule]

Response = none is defined in the language spec, but not 'required', http is not suitable for use cases that need response = none. I do not see the conflict, but if the general consensus is that there is indeed a conflict, then simply spell out in the transfer spec that https is not suitable for cyber-ecosystems that require response = none.

[sparrell]

I agree with Joe. I created the use case (for response equals none response to ddos attack) and I tried to implement in http for the plugfest. After much discussion in the Erlang community, I concluded requiring a response (in the http case) is a more practical solution. For that use case in pub sub the producer would not subscribe to the responses so no need for consumers to send (and there would be billions sending). Maybe appropriate text belongs in the use case (saying when to use: pubsub or a udp spa scheme; and when not: http/s). Maybe transport spec should say that option not supported in that transport and give informative reference to use case. And maybe affected actuator profiles (SLPF would be,many others would not) also reference use case

[Vasileios-Mavroeidis]

Plus 1 for Joe´s answer.

[dlemire60]

We appear to have a consensus. I'll propose some text to address this. This issue will stay open until we agree on appropriate text.

[dlemire60]

Proposed text in this commit: https://github.com/oasis-tcs/openc2-impl-https/pull/106/commits/299cc697b1bc51ec24b1a44fb11b92f99e7b055a

PR #106 includes that and other miscellaneous changes (all other changes non-normative).

[davaya]

It is technically impossible to use http(s) without a response. I agree with Joe's suggestion to discourage it. But "SHOULD NOT" means that a developer can choose not to follow the recommendation and still conform to the standard.

We should make it a MUST NOT (so that an implementation that does it is not conforming), and specify what happens when an implementation ignores the recommendation (the server returns a bad request error status 400 with no body). Both are needed, since a Consumer still needs to do something if it gets a request from a non-conforming Producer.

[sparrell]

I agree with “MUST NOT”. I don’t agree that we must specify behavior when system does something we say it must not do. I disagree with “ a Consumer still needs to do something if it gets a request from a non-conforming Producer”. Ie we do not need to define responses to all possible bad things that could be sent. I am ok to say it should be considered to be ‘response requested’ even if the said ‘none’.

Grammatical aside to @davaya comment: Technically it’s not technically impossible :-). I did figure out how to actually implement it but I agree it is not an appropriate solution since it’s not conformant with the HTTP specification. So I’m not disagreeing with concept just noting ‘technically impossible’ is not correct.

[dlemire60]

PR #106 updated per @davaya's input. Right now it includes the Consumer behavior language as he suggested. If I read @sparrell correctly, he's suggesting that an alternative is for the Consumer to ignore the response_requested = none and return a response anyway. I can live with either alternative, and am happy to be guided by people with implementation experience.

[sparrell]

I prefer the ‘ignore and return response anyway’ because it better handles if we do pub/sub interworking with http/s. I agree it’s a 2nd-order use case but it was demo’d at plugfest.

[davaya]

I'm OK with ignore.

[dlemire60]

How about:

An OpenC2 Consumer receiving a command containing "response_requested" : "none" SHOULD ignore the argument and return a response (i.e., operate as though the argument specified "complete"), but MAY return a status code of 400 with no body.

Or just drop the MAY clause?

[davaya]

They have the same effect on conformance - when you ignore a SHOULD, you automatically MAY do any (otherwise legal) thing instead. But I think it's useful to mention a specific possibility.

[dlemire60]

OK. PR #106 updated one more time. I think we have this nailed down now.

[dlemire60]

This issue and PR #106 were discussed at the 1 April meeting. The PR as written was not accepted.

• @sparrell prefers to treat this situation as an illegal command and deal with it like any other error condition.
• Other IC-SC members (@dmg2, @jmbrule) feel the Consumer should execute the command, honor the "none" argument with regard to the OpenC2 response, and allow the HTTPS server to return its own minimal response.
• @sparrell pointed out that this argument suited an IoT use case he had supplied, for which HTTPS would not be the preferred transfer protocol due to the huge number of Consumers involved
• @dlemire60 has confirmed, post-meeting, that in the Language Spec, section 3.3.1.4, the default for a Consumer when response_requested is not explicitly specified is to act as though "complete" was specified. (there was uncertainty about this during the meeting).

Proposed: apply the approach of

• the Consumer accepts the command
• the Consumer honors the "none" argument WRT the OpenC2 response
• the HTTPS server responds with a minimal success argument, 200, which should be interpreted by the Producer as indicating the command was successfully transferred to the Consumer with no implication regarding the Consumer's success in executing the command.

Language in the PR to be updated accordingly if this proposal is accepted.

[dlemire60]

The approach described in my 6 April comment was accepted by the IC-SC at the 6 May meeting. PR 106 will be revised accordingly.

[dlemire60]

Addressed by PR #106, closing this issue.