patconnole
commented
4 years ago Here's an example of the problem described:
OpenC2 Consumer behavior is undefined for consumers that implement multiple actuator profiles. For example, what are the expected behaviors in the table below, using the example commands?
We have two Actuator Profiles, say, StateLESS Packet Filtering, and StateFUL Packet Filtering, with overlapping commands:
query-features =
{
"action": "query",
"target": {
"features": ["versions", "profiles", "rate_limit"]
}
}
deny-ipv4_connection=
{
"action": "deny",
"ipv4_connection": {
"protocol": "tcp",
"src_port": 21
}
}OpenC2 HTTPS v1.0
- Rule 1: We are limited to 1 HTTP Response per POST (HTTP/1.1 doesn't have a way to respond multiple times to one POST)
- Rule 2: We are limited to 1 OpenC2 Response per HTTP Response (OpenC2 HTTPS v1.0 : "...contain only a single OpenC2 Command or Response message")
| SLPF | SLPF + SFPF | |
|---|---|---|
| Consumer Receives | Expected Consumer Behavior | Expected Consumer Behavior |
| query-features | ✅ 1 OpenC2 Response in 1 HTTP Response | ❌ undefined; |
| deny-ipv4_connection | ✅ 1 OpenC2 Response in 1 HTTP Response | ❌ undefined; |
There is no way to satisfy Rule 1 and Rule 2 if the Consumer implements SLPF and SFPF.
davaya
dlemire60
Problem: Much has been talked about OpenC2 sending one command to multiple consumers, presumably resulting in multiple responses back to the originating producer. Returning one response for each consumer queried seems reasonable and fairly well understood. However returning multiple responses for each consumer queried posses some interesting challenges. I want to explore this and bring to light some issues that should be addressed.
Assumptions: 1) We recognize that an OpenC2 producer can send one command to multiple consumers. 2) We recognize that an OpenC2 consumer can support multiple actuator profiles. 3) We recognize that OpenC2 commands have an "actuator" field which is utilized to "filter" a request. 4) We recognize that the "actuator" field allows for the specifying of one actuator or none at all. 5) We recognize that there is no way to specify more than one actuator besides not specifying one at all. 6) We recognize that not specifying an "actuator" results in a non filtered request which is handled by all available actuators.
Scenarios: In order to scope the following scenarios assume: 1) OpenC2 command is being sent to multiple consumers. 2) All Consumers support multiple actuator profiles.
Scenario#1: In the case of one "actuator" being specified in an OpenC2 command the result is that the consumer will send one response back to the producer. In this scenario the producer may receive multiple responses in total but only one from each consumer.
Scenario#2: In the case of no "actuator" being specified in an OpenC2 command the result is that the consumer sends more than one response back to the producer. In this scenario the producer will receive multiple responses from multiple consumers.
Scenario#3: Currently there is no way to specify more than one "actuator" but many have asked for this feature. In the case that multiple "actuators" are specified in an OpenC2 command a similar issue as in scenario#2 may be present.
Discussion: Focusing on Scenario#2 above we can see that not specifying an actuator in an OpenC2 command could lead to the consumer having to craft multiple responses. Since the OpenC2 specification does not have a way to concatenate responses it would seem that each of these multiple responses would have to be sent back to the producer individually. This posses an issue for some transfer types. Transfer types that utilize sessions such as HTTP/HTTPS would close the session once a response is sent, leaving the others to linger or fall off the queue. Concatenating them could alleviate this issue, but then it would open the door to other issues, such as how long should we wait before concatenating results and how do we do this with out affecting the way we validate individual actuator profile content. Lets not forget that actuator profiles can and will respond entirely different given the same "action-target" pair. One way to solve this without developing a concatenation method would be to simply put a stipulation on the use of transfer protocols that use sessions in this way, declaring that if you use them you have to explicitly state an "actuator" every time. This would mean forcing a new command id for each "actuator" derivative of the original command in order to check the status of those commands later. The same command id could be used across multiple consumers but not across multiple actuator profile derivatives. Open to solutions and discussions on this topic.
TLDR; Restrict OpenC2 due to limitations in the implementations transfer protocol OR Create a way to concatenate multiple actuator profile responses so that a consumer can reply only once.