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: [Non-DoD Source] [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender

At this week’s Actuator Profile SC meeting we discussed the NETCONF protocol, RFC 6241, and what lessons it might hold for OpenC2 design.  One of the critical lessons of IETF protocol development is layering – rather than sticking everything in one big structure, use a more modular approach with separation of concerns.   RFC 6241 divides the NETCONF space into four layers: Content, Operations, Messages, and Secure Transport.   I have just started a NETCONF use case to be included in the OpenC2 repo – it’s not even ready for a first PR yet, but some front matter is available from https://github.com/davaya/openc2-lsc-usecases/blob/master/DoD/02.netconf.md.


A few relevant quotes from RFC 6241:


NETCONF allows a client to discover the set of protocol extensions
supported by a server.  These "capabilities" permit the client to
adjust its behavior to take advantage of the features exposed by the

(OpenC2 should have a discovery/negotiation mechanism)


A NETCONF session is the logical connection between a network
administrator or network configuration application and a network
device.  A device MUST support at least one NETCONF session and
SHOULD support multiple sessions.

(OpenC2 should support sessions and session state, not copy state information into every message)


A NETCONF capability is a set of functionality that supplements the
base NETCONF specification.  The capability is identified by a
uniform resource identifier (URI) [RFC3986].

(OpenC2 actuator profiles extend the base Language Spec)


The NETCONF protocol can be layered on any transport protocol that
provides the required set of functionality.  It is not bound to any
particular transport protocol, but allows a mapping to define how it
can be implemented over any specific protocol.
NETCONF connections MUST be authenticated.  The transport protocol is
responsible for authentication of the server to the client and
authentication of the client to the server.
The authentication process MUST result in an authenticated client
identity whose permissions are known to the server.  The
authenticated identity of a client is commonly referred to as the
NETCONF username.

(OpenC2 can be used over any transport and security layers that meet specified requirements)


And lastly,

The NETCONF protocol uses an RPC-based communication model.  NETCONF
peers use <rpc> and <rpc-reply> elements to provide transport-
protocol-independent framing of NETCONF requests and responses.



This discussion of restructuring OpenC2 message payloads to include metadata is wrongheaded.  To and from and subject fields, timestamps, user agent identifiers and the like are metadata about a payload, not part of a payload.  OpenC2 payloads can be carried over many transports, including HTTP and OpenDXL.   Rather than redefining OpenC2 commands to include redundant header capability, OpenC2 should define whatever header-like information it needs as a transport dependency, in a manner analogous to NETCONF’s “authenticated identity” referred to above.


I am STRONGLY against re-inventing the wheel to put header information inside OpenC2 payloads.   Layered design exists for a reason, so that solutions can be composed from loosely-coupled building blocks.  Let’s re-use what’s already there, not re-invent it.






From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org] On Behalf Of duncan@sfractal.com
Sent: Friday, January 26, 2018 11:01 AM
To: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [Non-DoD Source] [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender


Remember we are discussing the language specification. I still think the language should have options and the actuator profiles and implementation specifications should have the mandatory.


This is a language not a protocol. It is the payload to ride on top on a (hopefully) secure mutually-authenticated protocol. For example, where the transport (eg when the link is a TLS API) can handle some of this, I believe it belongs there. I'm not arguing we don't have version - I just think in that case it belongs in the API URL not in the JSON. Ditto SENDER - authentication should be done by transport not in our JSON.


We are talking what goes in every single transaction at the command level. By my calculation we are talking about a 25-50% increase in the character count on an allow or deny command, which I feel will be the most common transaction. Yes it's doable. No it won't kill the use of openc2 if we add it. I won't fall on my sword over it, but I still think it's wrong to add that burden in cases where it's redundant (like version in URL and again in JSON) or unnecessary (like timestamp, sender).


I disagree that the burden is on the 'option' to justify the burden of the timestamp. To my knowledge, every use case presented did NOT have a timestamp sent in the command. To my knowledge, not a single production instance of the prototype language had a timestamp in the command. The two live uses I know of (Zepko, AT&T) both are multi-vendor (without the vendor's knowledge - they both wrote their own adapters) and don't have any of these fields and do not have any interoperability issues. Correct me if I am incorrect. I think there is sufficient proof that it not always necessary. Can someone at least supply a usecase where timestamp would be used?


One random aside related to previous paragraph - the fact


I still maintain these issues are all better understood with examples. Can someone supply them?


We may all be talking past each other since we are thinking different architectures. I am coming from the connection-oriented secure mutually authenticated link between a security orchestrator commanding an actuator. I am assuming both are within the same enterprise (as I can't conceive of any company allowing someone else changing their security posture) but many vendors involved and i could swap between them without changing the commands. I maintain this architecture will be the 99% case based on what exists in enterprises today, but others are welcome to dispute.


Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize


-------- Original Message --------
Subject: RE: [openc2-lang] We need your input on: mandatory vs optional,
Header, id, version, timestamp, sender
From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Date: Fri, January 26, 2018 9:37 am
To: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
Cc: Danny Martinez <danny.martinez@g2-inc.com>, Duncan Sparrell
<duncan@sfractal.com>, openc2-lang

To me, this email trail seems to be happening backwards, where folks are trying to justify why given fields should be mandatory - it should be flipped around. The justification should be on the optional side. What is the justification for an optional timestamp - in what situations is it a burden on the producer to provide one? Copy the above for every discussed field.

Optionality creates implementation difficulty with any protocol and any standard. The more things that are optional, the more decision branches you have to create, and the more input and error conditions you need to handle. It is also much more likely to create interoperability problems between products as they will end up with behavioral differences to the end user when the field is present or not present - things you can't cover in a data interchange specification.

Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems

"Things may come to those who wait, but only the things left by those who hustle." - Unknown

From:        "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
To:        Danny Martinez <danny.martinez@g2-inc.com>, Duncan Sparrell <duncan@sfractal.com>
Cc:        openc2-lang <openc2-lang@lists.oasis-open.org>
Date:        01/26/2018 10:17 AM
Subject:        RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
Sent by:        <openc2-lang@lists.oasis-open.org>

The interoperability question is the major consideration here. My experience in these matters has shown that if the goal of OpenC2 is to support multi-vendor, multi-product environments, then we need to ensure that the necessary bookkeeping information is required to be present to ensure this interoperability. Making these fields optional may allow for less information to be provided in single-vendor scenarios, but this is at the cost of ensuring interoperability in multi-vendor scenarios. For OpenC2 to be successful, we need to support both situations. If these fields (except version timestamp) are not made mandatory, there is no guarantee that these fields will be provided by all implementations. This will create a usability problem that is rooted not in implementation, but in the standard itself.
The version question is a larger question of implementation agility. OpenC2 will evolve over time and it is important for tools to have the data needed to support this agility. This issue is lessened, but not eliminated in a single-vendor scenario where agreement on the version can be managed across the deployed solution. Even in the single vendor scenario, it is unlikely that all components can be updated simultaneously. This means that different components in the deployed architecture will need to be upgraded individually. Different components will need to be operating at differing revision levels, where version is helpful. This is exacerbated in multi-vendor scenarios where this issue will almost always be present.
I don’t believe the dozen or two bytes of extra information will make or break implementations or deployments. In my view it’s worth the gain in interoperability that will result. Perhaps we should be discussing how these fields can be incorporated at both the individual command level and in collections of commands. IMHO, COMMAND-ID should be expressed as a  at the individual command level. Fields like VERSION can be expressed in a collections of commands, or if a single command is being sent at the individual command level. The requirement needs to be that it must appear at the individual command level if the command is not being exchanged as part of a larger collection of commands, or if the command follows a different model version than other commands being exchange in a collection. This approach would allow for a few bytes to be saved around the VERSION, but is at the cost of additional complexity. I am not sure the extra complexity is worth it, but this should be considered with regards to the language spec.
From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org] On Behalf Of Danny Martinez
Thursday, January 25, 2018 7:42 PM
Duncan Sparrell <duncan@sfractal.com>
openc2-lang <openc2-lang@lists.oasis-open.org>
Re: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender

I have not weighed in until now because I do not entirely understand what the issue is here. As I understand it is not whether these fields should exist at all, but rather if the fields should be mandatory or optional. My problem is why is the LCS even having this conversation? It seems more of an implementations consideration question to me. In effect I think both arguments are valid potential implementations of the OpenC2 language.
The question then comes in. Well  if we leave everything up in the air to be implemented any which way then we will never have interoperability. I agree and this is precisely why I have been a big advocate of having a "minimum implementations to conform". It is one thing to say my implementation is viable, and another to say my implementation interoperates with other implementation. Currently when we create a reference implementation we have the benefit to "fix the fight" we can choose what happens on both sides of the communications path. This will not always be the case.
From a language spec perspective I believe these options should be "optional", but I would not be oppose to making them "mandatory" for a particular implementation. If this implementation ends up being our "minimum implementation to conform" then in I agree that these options should be "mandatory".
On Thu, Jan 25, 2018 at 4:04 PM, <duncan@sfractal.com> wrote:
So 5 of the 29 LSC members have weighed in within 24 hours. Ideally I'd like to give at least another day or so to hear from a few others - and not just because my view is losing at the moment :-).
And it's a slightly more nuanced vote that 3 to 2 since I read Dave's note as for most of Allan's proposal but agreeing with me that timestamp should be optional (ie for timestamp its 3/2 the other way).
Everyone else - please let us know your opinions. Even if your opinion is "I don't care either way, just get on with it" - that is valuable input also (and shows you are listening and care).
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE:
[openc2-lang] mandatory vs optional, Header, id, version, timestamp,
From: Bret Jordan <
Date: Thu, January 25, 2018 3:29 pm
To: "Brule, Joseph M" <
jmbrule@radium.ncsc.mil>, "'duncan@sfractal.com'"
duncan@sfractal.com>, openc2-lang <openc2-lang@lists.oasis-open.org>
So Duncan and Joe are against it.  Allan, Bret, and Dave are for it.

--------------------------------------------------------------------- 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


Danny Martinez

Cybersecurity Engineer

G2, Inc.

302 Sentinel Drive, Suite 300

Annapolis Junction, MD 20701

Mobile: 407-257-0031


--------------------------------------------------------------------- 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

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