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
device.
(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.
Dave
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.
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
<openc2-lang@lists.oasis-open.org>
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
www.ibm.com/security
"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.
Regards,
Dave
From:
openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org]
On Behalf Of Danny Martinez
Sent: Thursday, January 25, 2018 7:42 PM
To: Duncan Sparrell <duncan@sfractal.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
All,
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".
V/R
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,
sender
From: Bret Jordan <Bret_Jordan@symantec.com>
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.
Bret
--------------------------------------------------------------------- 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
--
302 Sentinel Drive, Suite 300
Annapolis Junction, MD 20701
--------------------------------------------------------------------- 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