PRD-02 Comments for SLPF Profile (in bulk)

[Brian Berliner <Brian_Berliner@symantec.com>]

[[ I wasnât planning to comment on the SLPF spec for the PRD-02 deliverable, since Iâm not supporting it in my product today, but a quick scan through it caught a few topics of discussion, so even though this is âafter the official PRD review timeframeâ, please consider them as comments from myself as a TC member]]

 

As a member of the Technical Committee, the OASIS process requires that I send my own comments to the TC directly, as opposed to using the openc2-comments mailing list. As such, I have combined all my comments into this single message (and, hopefully, sent them to the proper list!).

 

These comments are related to Profile for Stateless Packet Filtering Version PRD-02 (dated April 04, 2019; PDF version).

 

1. Section 1.4, Page 10: Should have a link to the âActive Cyber Defenseâ paper, which is https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8

 

2. Section 1.4, Page 10: Should have a link to the âIntegrated Adaptive Cyberspace Defenseâ paper, which is https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762

 

3. Section 1.5.2, Page 11: The first example shown for OpenC2 in the spec is not compliant with the spec as it refers to a âuser_accountâ target, which is not part of the language. The very first example that readers see should accurately reflect a compliant command, like a âdeny/file/hashes/sha256â command. I can supply an example if necessary, but using âuser_accountâ definitely feels wrong to me at this spot in the document.

 

4. Section 1.6, Page 14: The description for the âMessageâ layer uses the term ârequestsâ and âresponsesâ. In the Terminology section (1.2, Page 8) there is no definition of what a request is; only what a command is. The previous page (13) describes a âCommandâ and âResponseâ payload, which is correct, yet we seem to talk about Message in terms of âRequestâ and âResponseâ. I think there is a disconnect in the Language Spec. I think the description of the Message layer should read: âThe Message layer provides a transfer- and content-independent mechanism for conveying Commands and Responses. A transfer specification maps transfer-specific protocol elements to a transfer-independent set of message elements consisting of content and associated metadata.â This clarification should bubble up into the other specs (since this is common boilerplate that is currently copied to all 3 specs), and the âmsg_typeâ description in the Language Spec (Table 3-1, Page 31) should be changed to say âOne of command or response. For the application/openc2 content_type the request content is an OpenC2-Command and the response content is an OpenC2-Response.â, which is correct and also more consistent (the command and response stuff now matches perfectly). And finally, note that the Language Spec ârequest_idâ field in that same table says âA unique identifier created by the producer and copied by consumer into all responses, in order to support reference to a particular command, transaction or event chain.â which, even though the field has ârequestâ in its name, describes only a âcommandâ in the description (and also doesnât appear to properly capitalize the âProducerâ or âConsumerâ or âCommandâ parts here either, but thatâs a different subject). There is clearly some terminology looseness that I feel can be tightened up easily.

 

5. Table 2.1.3-2, Page 22: The ârunningâ field seems oddly named to me. The description explains that normall any config changes are made persistently, but the word used to change this fact is ârunningâ. Why wouldnât we choose âpersistâ as the Boolean or âpersistentâ instead? So, the default for the âpersistâ field would be TRUE, but you could override this by setting âpersistâ to FALSE. To me, that is clearer than ârunningâ, which is a state that is independent of whether a configuration is persistent (or non-volatile). I donât feel strongly about this comment, but wanted to throw it out there for discussionâ

 

6. Table 2.1.3-2, Page 22: For the âdirectionâ field, I find it odd to use an enumeration here, as there appears to be only two possible things that would be enumerated (âingressâ or âegressâ. If there are only ever two possible options, a Boolean may make more sense, or the addition of a âbothâ option to the enumeration to explicitly set the rule to include both (which is the default). Again, I donât feel strongly about this, but the use of enumerations for two possible items would usually result in an architectural discussion for meâ

 

7. Table 2.3-1, Page 26: Love the table, and itâs a great example for other Profiles to use. However, this particular profile does appear to support OPTIONAL action/target pairs, and it would be nice to indicate the OPTIONAL ones in this table (like with an asterisk [*] or something) instead of having to discover the OPTIONAL ones in the text details. This is strictly an editorial suggestion to improve readability.

 

8. Section A.1.1, Page 42: The example Command uses an âactuatorâ with a single field of âslpf:asset_idâ, but this does not match the exact same example included with the Language Spec PRD-02 Section 3.1.5, Page 28, which shows an example of a higher-level âslpfâ field with a sub-field of âasset_idâ. These discrepancies need to be resolved at our Face2Face meetingâ

 

9. Section A.1.2, Page 43: The example for deny/ip_connection is specifying a Target of âip_connectionâ, which is not a valid target in the Language Spec, so this example is invalid and misleading.

 

10. Section A.1.3, Page 44: Same comment as above about the use of the âslpfâ field in the âactuatorâ object (the Language spec implies that all these fields should be under the âslpfâ filed, which is itself under the âactuatorâ top-level field.

 

11. Section A.3, Page 46: The example update/file Command uses an âactuatorâ with a single field of âslpf:named_groupâ, but this does not match the similar example included with the Language Spec PRD-02 Section 3.1.5, Page 28, which shows an example of a higher-level âslpfâ field with a sub-field of âasset_idâ. These discrepancies need to be resolved at our Face2Face meetingâ

 

12. Section A.4.1, Page 47: The example included for the âqueryâ Action is using an âopenc2â target, which no longer exists. This needs to be changed to âfeaturesâ to be a compliant example.
13. Section A.4.3, Page 48: The example response for the query/features/profiles command implies that a returned profile can have more than 16 characters (âiot-front-door-lockâ), though the Language Spec PRD-02 says in Section 4.4.2.10, Page 45, that the NSID for a Profile must not be longer than 16 characters. So, we need to fix one or both of these to be consistent.
14. Section A.4.4, Page 49: The example response for the query/features/pairs command is using the wrong JSON response format. The Language Spec PRD-02, Section 3.4.2.1, Page 43, defines the âpairsâ field as being a Map where the key is the Action (as a String) and the supported targets for that Action is an array of Targets (as a string).
15. Annex C, Page 51: Feel free to add me to the Acknowledgements section if you apply any of these comments to the final version (Thanks!).