Hmmm.
I tend to assume that the ability to support non-secure transport is at
a device level. That is, and I2RS Agent supports both, or it doesn't.
If we want enforceable controls over which data can be sent over which
channels, we are opening a very large additional can of worms. No, the
Module is not the right basis, since a module typically includes
writeable, readable, and notification related information.
The Node seems equally bad, since trying to guess at Module design team
which nodes will be needed by which monitoring and telemetry operations,
or will be provided by which kinds of devices, or will be used within vs
across organizational boundaries, seems unknowable.
Given that the I2RS approach is to let the operator use the tools in the
way he wants, I think the only practical solution is to let him use the
channels the way he wants.
Yours,
Joel
On 5/26/16 2:16 PM, Susan Hares wrote:
Joel:
<wg chair hat off>
<author hat on>
Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says:
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over a
non-secure transport. A secure transport MUST provide data
confidentiality, data integrity, and replay prevention.
The default I2RS transport is a secure transport.
A non-secure transport can be can be used for publishing telemetry
data or other operational state that was specifically indicated to
non-confidential in the data model in the Yang syntax.
The configuration of ephemeral data in the I2RS Agent by the I2RS
client SHOULD be done over a secure transport. It is anticipated
that the passing of most I2RS ephemeral state operational status
SHOULD be done over a secure transport. As
[I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate
whether the transport exchanging the data between I2RS client and
I2RS agent is secure or insecure. The default mode of transport is
secure so data models SHOULD clearly annotate what data nodes can be
passed over an insecure connection.
=============
Are you trying to suggest that the ability to do secure transports should be
at the data model level? If so, does this text change work for you:
Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that
nodes have the following properties: ephemeral, writable/not-writable and
status/configuration. Yang MUST have a way to indicate
whether data models can be passed over secure or non-secure transport.
(If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for
potential yang syntax).
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern
Sent: Thursday, May 26, 2016 1:47 PM
To: Susan Hares; [email protected]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security
We could take the view that all nodes in a model being used by I2RS had to
have the potential to be ephemeral. While that would be attractive for
consistency, it puts a massive burden on the routing system implemention.
So we agreed that ephemeral marking was on a per-node basis. Yes, that
means that the model designer has to look at the usage. Unfortunate, but a
tradeoff.
When it comes to securing the transfer, the situation is very different.
Most importantly, the cost for supporting sending whatever the client
requests over an unsecure transport is small. And trying to guess which
information will be needed by monitoring or telemetry seems like to end up
with "all". Yes, there is a security risk with saying that telemetry
information may be send unencrypted. But either wwe accept that or we
don't. Trying to do node based marking does not seem to help the situation,
and it creates operational restrictions and complications.
Yours,
joel
On 5/26/16 1:08 PM, Susan Hares wrote:
Joel:
The purpose of allowing a non-security transport was to report status or
telemetry information. This information may be in a specific model, or a
portion of a model. While nodes may be too small an area, can you
suggest
alternate wording here?
Please look at Ephemeral-REQ-05 for context of the use of "object"
Sue
-----------
Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model
that nodes have the following properties: ephemeral, writable/not-
writable, status/configuration, and secure/non-secure transport. (If
you desire examples, please see [I-D.hares-i2rs-protocol-strawman]
for potential yang syntax).
Ephemeral-REQ-05: The ability to augment an object with appropriate
YANG structures that have the property of being ephemeral. An object
defined as Yang module, schema tree, a schema node, submodule or
components of a submodule (derived types, groupings, data node, RPCs,
actions, and notifications".
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel Halpern
Sent: Wednesday, May 25, 2016 11:17 PM
To: [email protected]
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security
While I agree with the overall requirement that I2RS support both
secured and unsecured communication, I find Ephemeral-REQ-06 rather
odd. Trying to have the module designer specify whether the usage of
a node (get, set,
...?) must be via a secure or unsecure transport seems a very odd
placement of the control.
Why are we mandating this on a per-node level?
Thank you,
Joel
On 5/25/16 9:39 PM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of
the
IETF.
Title : I2RS Ephemeral State Requirements
Authors : Jeff Haas
Susan Hares
Filename : draft-ietf-i2rs-ephemeral-state-07.txt
Pages : 14
Date : 2016-05-25
Abstract:
This document covers requests to the NETMOD and NETCONF Working
Groups for functionality to support the ephemeral state requirements
to implement the I2RS architecture.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
