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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod