Dear all,
As discussed during the IESG telechat today, we should only focus on the
addition of the RESTCONF bits, and not attempt to include the I2RS
future protocol now.
Hence this minimum change proposal:
The YANG module defined in this document is designed to be
accessed via network management protocols such as NETCONF
[RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the
secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF
layer is HTTPS, and the mandatory-to-implement secure
transport is
TLS [RFC5246].
The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
pre-configured subset of all available NETCONF or RESTCONF
protocol operations and content.
Regards, Benoit
On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote:
Keep in mind that I2RS believes in a requirement for cleartext
transport protocols. Perhaps this never makes it through the IESG but
so far it was not possible to stop this...
This is solely for notifications that can be sent, just as IPFIX
information may
be sent unencrypted. Those requirements are in
draft-ietf-i2rs-protocol-security-requirements-17
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>,
which is in the RFC Editor queue.
The new features are priority, an opaque secondary identifier, and an
insecure protocol for read-only data constrained to specific standard
usages.
The optional insecure transport can only be used
restricted set of publically data available (events or information)
or a select set of legacy data. Data passed over the insecure
transport channel MUST NOT contain any data which identifies a
person.
I think your statement that it is only for notifications is wrong.
The fact that some data ships in a notification does not mean the data
is not sensitive. Furthermore, I think we all meanwhile know that
IPFIX data is highly sensitive if you have the right context
information (so the analogy is flawed). And what the heck is a 'select
set of legacy data'?
SEC-REQ-06: An I2RS agent receiving an I2RS message over an
insecure transport MUST confirm that the content is suitable for
transfer over such a transport.
An agent can't decide this. It is the context information that often
decides whether a piece of information is sensitive or not. So the
only decision an agent can do is to only allow messages with empty
content over an insecure transport.
The I2RS architecture defines three scopes: read, write, and
notification scope. Insecure data can only be used for read scope
and notification scope of "non-confidential data".
I understand that the IESG approved the security requirements. I do
not know why the security ADs did let this pass - perhaps since the
document is just about requirements and they will look closer at a
solution and then ask questions what 'non-confidentail' data' is, what
a 'select set of legacy data' is, or how an agent confirms that the
content of messages is suitable for an insecure transport.
Anyway, this does not belong here, the point I wanted to make is
simply that Kent's assumption that a protocol transporting YANG
defined data is always protecting the data is not true from the
viewpoint of the I2RS proponents. Thanks for confirming this.
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
