Multiple Profiles

[davaya]

Deployed OpenC2 solutions require the ability to specify more than set of actuator specifiers in a command. Each actuator profile defines a set of specifiers related to its function, and an OpenC2 Consumer may support more than one profile.

Propose that the type of "Actuator" be changed from Choice (which allows only one actuator type) to Map (which allows more than one type). A Consumer that receives a command containing more then one actuator type MUST ignore all types not included in its set of supported profiles.

[bberliner]

We are using this capability in our implementation already today, but currently only with extensions (profiles that begin with x-), so I would want this ask to work for "official" profiles as well as extension profiles.

Our OpenC2 Proxy, today, can handle multiple actuator specifiers AND multiple args specifiers (and I don't recall off-hand if the 1.0 spec allows for multiple with args already, but if it doesn't, then we may need another issue open to discuss that one).

[jmbrule]

Really good point davaya. If we are running https stars then this is not particularly interesting, but if we have a pub/sub or some sort of multi-cast environment, it makes sense to be able to specify more than one, but not necessarily ALL actuators that can execute some action target pair.
For purposes of the pull request, do we need to add some sort of explanatory text? Or can we get away with a simple mod from 'choice' to 'map'?

[jmbrule]

So is the idea along the lines of, if you have a base command (ACTION, TARGET) and no actuator profile then any actuator that can execute the command should, but if you have (ACTION, TARGET, ACTUATOR(S)) then any actuator that is not explicitly spelled out in the command should not execute the command?

[davaya]

We will need to document a decision tree based on: 1) commands are addressed to, and received by, a set of actuator devices. 2) a device supports one or more profiles 3) a device executes each of its profiles separately, by each "function unit" on the device 4) actuator specifiers filter down (yes/no decision to attempt) execution within the device's named "function unit", independent of other profiles supported by the device. Actuator specifiers don't modify how a command is performed - that's command args. For device that supports "slpf" and "sbom" profiles and receives a command with slpf actuator specifiers, the sbom function unit behaves exactly as if the command didn't have any actuator specifiers.

So the question is reduced to "what does a "slpf" function unit do with a command with no actuator field, where the command is valid according to the slpf profile"? And what does it do if the command is not valid? That will require some thought.

[davaya]

See https://github.com/oasis-tcs/openc2-oc2ls/issues/365

[dlemire60]

I believe this is still a valid questions. Triage should either be "resolve for LS v1.1" or "defer to future version".

[dlemire60]

PR #404, addressing Issue #398, changed the command Actuator field from (Actuator : Choice) to (Profile : Enum). This clarifies the intent of the field as specifying the desired profile, but still imposes a “zero or one” cardinality (i.e., it limits a command to only specify one profile). This write-up attempts to capture discussion how consumers that support multiple profiles respond to commands that are applicable to more than one supported Profile and suggest an implementation approach that could be added to the LS.

Assumptions

1) Command Profile field gets changed to type Map to enable invoking multiple profiles (as per @davaya's opening comment on this issue) 1) Consumers involved implement multiple profiles 1) Profiles may have overlapping coverage of specific commands

• (e.g., “deny : ipv4_address” may be supported by multiple profiles) 1) Consumer, as top level device / communications interface responds to LS mandatory command(s) (i.e., "query features"), including data from implemented profiles
• knows correlation of profiles / supported commands for internal routing
  • this might need to be stated as an assumption in the LS
  • this is consistent with the design patterns in AS section 2.3

Implementation Approach

Scenario 1: No Profile specified in command

• Consumer routes command to all profiles that support it
  • will have response from each applicable profile
  • need a solution to consolidating and returning multiple responses (model on PR# 435)

Scenario 2: Profile(s) specified in command

• Consumer with at least one specified profile: routes command to specified profile(s) that support it:

  • can have response from each applicable profile
  • multiple profiles again means need a solution to consolidating multiple responses (model on PR# 435)

• Consumer without any of the specified profiles (interpreting per LS section 3.3.1.4):

  • response_requested = none -- ignore command
  • response_requested = ack -- send status “102”
  • response_requested = status -- send status “501" (not implemented)
  • response_requested = complete -- send status “501" (not implemented)

Message Transfer

In a pub/sub implementation, a command to multiple profiles could be

• sent / received on all of the specified profile topics (e.g., oc2/cmd/ap/profile1, oc2/cmd/ap/profile2)
  • Could all be sent with the same command_id or a distinct command_id per profile
  • To the consumer these would appear as individual commands, one per profile, so there's no need to consolidate responses
• sent / received on general command channel (i.e., oc2/cmd/all)
  • By definition same command to all (= same command_id)
  • A consumer with at least one specified profile would respond per Scenario 2 above

[dlemire60]

Renamed this issue from Multiple Actuators to Multiple Profiles based on PR #404 having been merged.