On Thu, May 26, 2016 at 11:35 AM, Joel M. Halpern <[email protected]> wrote:
> 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. > > I think I agree with you. Take SNMP no-auth/no-priv as an example. It is a deployment decision whether or not to allow that. NETCONF and RESTCONF do not support non-secure transports so I assume a new document standardizing new transports would be needed. The RFCs actually say the protocol MUST NOT be used over a non-secure transport, so maybe a different protocol has to be used for this purpose. The NACM extensions make sense for subtree-level tagging. These alter the default NACM behavior for the subtree. The I2RS tag could be useful it there was agreement the node was non-secure in every possible application and no operator could ever disagree with this WG decision for any reason. IMO that will never happen. It is fairly easy in the server implementation to check whether the node being sent on a non-secure stream is tagged as "nonsecure OK". It is harder on readers and writers than tool makers. > Yours, > Joel > Andy > > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
