OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-lang message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender

So Duncan and Joe are against it.  Allan, Bret, and Dave are for it. 


From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> on behalf of Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Thursday, January 25, 2018 9:58:53 AM
To: 'duncan@sfractal.com'; openc2-lang
Subject: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender

Speaking as an OpenC2 TC member representing DOD and not as chair; 


I agree with Duncan.


      The focus of OpenC2 has been on unambiguous M2M exchanges and we have always strived to be low overhead and agnostic of other functional blocks.  These (and other) principles and assumptions have been in place since the TC’s inception.   

      Any analysis for the inclusion (or exclusion) of a particular feature should be optimized for operations rather than development. Though I can appreciate the challenges that product developers face, as a representative of an agency that is a non-trivial consumer of IT and security products,  we are interested in operations.

      The cost of additional fields is more than ‘a few bytes’.  Need to consider complexity.  Vulnerabilities can be a function on the order or 2^complexity.  Integration costs increase with complexity.

      Simplicity and low overhead is beneficial when one considers the environment, such as the verbosity of the C2, heterogeneity of the environment, the number of connected devices which is growing exponentially.  BTW I acknowledge that ‘exponential growth’ is arguably the most abused cliché ever but is OK in this context.


     There has been some discussion of ‘headers vs options field’ and ‘metadata vs header’.  I fail to understand why one needs to have some options in header fields and other options in an option field or some hybrid where we have optional headers and optional options.  Is there a compelling reason to have ‘metadata’ type of options in one field and different options in other fields?   I took the liberty of googling IPV6.  Some of the IPV6 options (in the options field) include routing, fragmentation, security payload header, authentication header, host identity protocol and others.  IPV6 will probably succeed ;-) despite the fact that different types of options were in the same ‘options’ field….


In the context of particular options:

     Command-id:  A valuable option and likely to be used widely, but not mandatory.  There are use cases (interdomain effects based comes to mind) where the id is not needed and there are others where it is critical.  Of all the options discussed, id is the option that one could make the strongest case for making mandatory, but at this point I consider it optional.

     Version: We certainly need to know the version and the versions have to be compatible, but is it necessary to include on each and every message?  Can the version be determined at initialization, or during a negotiation procedure?  One could contrive a possible scenario where a product has multiple capabilities and some of the capabilities are on version 1 and others are on a different version, so having the version on each and every message could be a useful option.  Having said that, this is a hypothetical argument for an option not a mandatory header.

     Timestamp:  A nice option, but clearly can be treated as an external dependency. In addition to Duncan’s points, there are numerous other protocols that address logging, audit etc. thus a ‘mandatory’ timestamp on every command is not needed for a wide range of use cases/ environments.    

     Sender:  OpenC2 is at the application layer.  Lower on the stack there are multiple fields that could be used for purposes of identifying the sender.  At this point,  I do not see sender as a particularly useful option, let alone ‘mandatory’ for each and every command,  however this can be revisited once the use cases are brought to the LSC.




Joe Brule


From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org] On Behalf Of duncan@sfractal.com
Sent: Wednesday, January 24, 2018 11:08 PM
To: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender



We can agree to disagree. Your opinions are based on your 'experience of protocol and product development making it easier to develop and debug production code.'. Mine is based on my experience doing the same. I'm guessing, but I don't know, that I put less emphasis than you do on 'design/debug' and more about steady state operations.

If there are architectures/transport protocols/actuators where they  are mandatory, then make them mandatory in those specs - not in the language. I've explained my reasons why I don't think they should be mandatory in the Language Spec for every command every time in all architectures/transports/actuators. You disagree. Our views cancel each other out. Let's hear from others.


Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize


-------- Original Message --------
Subject: Re: [openc2-lang] mandatory vs optional, Header, id, version,
timestamp, sender
From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wed, January 24, 2018 6:24 pm
To: "duncan@sfractal.com" <duncan@sfractal.com>, openc2-lang

Duncan  et al –


The suggestion to add these parameters was based on experience of protocol and product development making it easier to develop and debug production code. I agree in some use cases these parameters might not be needed when things just work or everything is homogenous environment but we are designing a specification for a protocol that must support different tools, different versions, different environments and therefore we need to design the protocol for those cases. Including these fields is not a major problem for *any* programming environment. All of the data is known by the programming and environment that any tool will be deployed in. What harm exists if these parameters mandatory? The # of bytes added to the message is minimal. That is not a strong argument for making them optional.


Command-Id -> there is no reason why this can’t be mandatory. This is a common construct across many protocols and applications using those protocols. Optionality just introduces complexity when implementations can easily support creating such a parameter. This parameter is useful for tracking and also matching up responses to commands. It allows products to show to users that commands have been received correctly and what their responses were. If a use case does not require this capability then just set the command-id to an incrementing number and ignore the response’s value returning it.


Version -> A version of protocol/schema being used to construct a message is 100% always known. Programmers that write code have to know what version of the protocol they’re writing to. Including this parameter in the messages is useful for compatibility checking, verification that one system is talking to another that is compatibility and is just common sense for debugging problems. If there are problems connecting systems together this will be one of the first questions a developer will want on why the commands are not executing correctly. For systems that don’t care about this checking then just hard-code the value and ignore compability checks.


Timestamp -> Same rationale as version. Every logging function on the planet generates log messages with timestamps. Time is known when a message is created. It is easily available to be included in messages. Its useful for debugging and cross-correlation across systems. If a system doesn’t care about it then just ignore its value. Mandating that the field be filled in is hardly a problem for any programmer to include a timestamp.


Allan Thomson,

This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed.  If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited


From: <openc2-lang@lists.oasis-open.org> on behalf of "duncan@sfractal.com" <duncan@sfractal.com>
Date: Wednesday, January 24, 2018 at 6:51 AM
To: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender



Optional/Mandatory - Language/Actuator/Implementation

There was discussion of whether a field should be mandatory or optional. I think we need to take into account the mandatory/optional decision is made in several places. If we make a field mandatory in the language specification then it is mandatory in all implementations in all architectures for all profiles. We should remember that a field can be optional in the language specification but required by either a profile (eg all firewalls SHALL implement COMMAND-ID per language spec blah blah) or by an implementation specification (eg all OpenDSS OC2 implementations SHALL implement COMMAND-ID ...). I say this so you have context for what follows in the email. In the LSC, we can only determine the optional/mandatory for the Language Specification and will leave it to the AP-SC for profiles and IC-SC for implementation. 



Yesterday at the LSC I think we reached consensus among those present that a COMMAND-ID capability should go in the language. I propose the field name be “id”, not “command-id”. I am distinguishing between what we humans refer to the field (COMMAND-ID in upper case) vs the ascii string that goes in the JSON (“id” in lower case). I think it’s important to remember there is hierarchical context within the JSON and we don’t need to burden the field names with information humans need when discussing it. “id” would be unambiguous in the JSON to both machines and humans.


In the case of COMMAND-ID, my gut says it should be optional in the language specification but I could be convinced to make it mandatory. In my use cases, I need it sometimes and not others. Ie I have use cases where I don’t need it but I don’t see it as an burden to add it for those use cases.



Where I feel more strongly is in the discussions of other field we lumped with COMMAND-ID. For the benefit of those not present at the discussion (and to record it for posterity since it’s bound to resurface) there is a proposal on the table to distinguish between two types of fields that are currently lumped under COMMAND-OPTIONS. The proposal was made to pull out what (I think it was Allan) called ‘HEADER’ or (I think it was Danny) called ‘METADATA’. I.e. they aren’t really options in the sense that they are part of executing the command like the ‘DELAY’ option is. I believe the “options” that got lumped in the HEADER category include VERSION, TIMESTAMP, SENDER, and COMMAND-ID.


Although I maybe could be convinced to make COMMAND-ID mandatory, I feel strongly that VERSION, TIMESTAMP, SENDER should be optional in the Language Spec. One suggestion was to make HEADER optional - but, if included, then ID, VERSION, TIMESTAMP, SENDER are mandatory. I disagree with that approach - i.e. I would like to optionally use ID without being forced to include the others.



In my use cases, I only send commands over a secure, mutually-authenticated communications channel. I personally would never recommend executing a security command based on the SENDER field - I’d need something more for authentication, and if I had it - then I wouldn’t need the SENDER field. I’d welcome someone documenting a use case, that they need and would implement, where SENDER is needed. I recognize I don’t know everything, but I would insist someone pull out their black pen and document that they will use it (i.e. I personally won’t be swayed by hypothetical, but I would agree based on a stated need by a member that they need it and would use it). In the past, it seems to come up in discussions where STIX COA use cases are mentioned. Maybe I just don’t understand that use case and I’d welcome someone documenting it. Assuming such a use case gets documented, I’d agree to it as an option but not as mandatory. This might get us into the 80/20 discussions of which uses are more common (with implication that if 80%, make it mandatory). But I feel those arguments belong in AP-SC and IC-SC since I feel they will be actuator and architecture dependent.



In my use cases, I at the moment only send commands point-to-point between a security orchestrator (SO) and an actuator (A) over mutually authenticated (read the use case for details of CSA SPA used) link carrying an API. In my use cases I do not need a TIMESTAMP in the sense of ‘when was the command sent?’. As shown in my use cases, I do need (as an option, i.e. not on every command, but sometimes) the COMMAND-OPTION of allowing for the command to have a duration associated with it (i.e. ‘classic’ command options). I recognize in the future my security orchestrator may receive commands from ‘elsewhere’ (eg if the Small Business Administration offered a STIX/TAXII feed with COA in it, or my cloud providers, Amazon and/or RackSpace, send me openc2 about stuff they found). So I will distinguish between the SO-A and SO-SO and confess I don't have fleshed out SO-SO use cases and maybe TIMESTAMP makes sense there. If someone were to submit a black pen use case that they need the HEADER TIMESTAMP, I’d agree to it as an option but not as mandatory.


I’ll use a fictitious example to make my point on language-optional, implementation-mandatory. Maybe the pubsub implementors all feel TIMESTAMP is required on all OpenDSS implementations (this is for explanatory purposes, I don’t know OpenDSS well enough to know it this is true); then the OC2-on-OpenDSS spec by the IC-SC could make TIMESTAMP mandatory while at the same time their HTTPS-API spec specifies it SHALL NOT be used (again for illustrative purposes). My point is it should be optional (if exists at all - someone supply a use case) not mandatory in the Language Specification.



Although I do agree we should future proof the language specification to the extent possible, I don’t feel we need to go overboard on future proofing. My use cases are all software in the cloud so are less constrained then those dealing with hardware or less updatable software. I feel that since no one implements OC2 yet, it's not unreasonable to assume future implementations will have updatable software. All my use cases are API’s. I believe API versioning is dependent on language versioning and will suffice for all my needs. Ie the language does not need to include a version in every command since the API will. I will defer to what the IC-SC decides for OC2-on-API but I will recommend in that group that the version be part of the URL (as opposed to a passed parameter) - ie it will be mandatory. I recognize there are other architectures than https API. Assuming such a use case where VERSION is needed gets documented, I’d agree to VERSION as an option but not as mandatory.


Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://clicktime.symantec.com/a/1/ejNqXPWYM5L8lslAzQ-_t5VfxMtHYuRxyGFFsmE2pFU=?d=oab0Np-pNxsUQWO8f74TxTvjCl9tW_cS0RjQ7Q4oh4qZl4mmjuQfIYakCB_kaemvaguuQgYlNAxGFE_ba-IBcJVMCFUjdzGEUOWcy2E5pGwzPqrWhgsMg1oHBgMSetzLGTD_RtpR9CD3p61IWrJk7dANVoyiSpUHhcWqbx4GKvHjdUwOEWh1RyNuRW2Kofj7hbbPjwbiYb2jZL4QMpZbupYHQEV9rNxanpOTz0lRVnH2rplUP7dEbkRvZgSArXwANznv1TnaBo2HTtGlXOXbPCsrdTzOGDduzDhPxkniqsy7OC21YSiIg4weXh2zQBAKHEOA_XZH-vXN7YoY77f3pWOODjYWwBhG9ZXrxrW-ukmPVEQ2giHRFxoD-XtFH6TVJH2Sbaeb2tGbnFKddz2ELMnMFWJY6XijEDMvTmvaCY--SD_ox5vSuMU0-J_2uC_F7t-roXpalFYWFiVHF8ea0BZCteKsPRMeThUzelIR9T3xDLlGLisJttoaY6hIu_9pXhAgflxvu8t4S2nbZQdbaZOs8YG2q5m9w8k2eKCPevWXiA%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]