The more I read the text about marking secure or insecure transports,
the I wonder whether it is an I2RS requirement at all.
that is, I2RS requires the ability to send notifications via an insecure
channel.
I don't think I2RS cares what granularity this is marked at.
There are security reasons for wanting to restrict the usage. Equally,
one needs any definition of some usage to be done by the entity which
actually knows what is needed.
I2RS as a system does not know or care how to resolve that tension.
So lets not state a requirement on it?
Jeff, you allude to using a protocol like IPFIX. Given that IPFix won't
be reading these YANG models at all, it seems that the requirement as
stated (marking in the YANG which nodes are allowed to be transferred
insecurely) won't help solve the problem.
I also wonder if the very notion of an I2RS protocol is getting in the
way. If the insecure transfer we envision is some protocol other than
NetConf / RestConf, then we seem to be stating the requirement in the
wrong place.
Yours,
Joel
On 5/31/16 3:36 PM, Jeffrey Haas wrote:
...
On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote:
...
2. Does Ephemeral-REQ-06 provide the Yang requirements in
a clear fashion? Do you have any suggestions for alternative text?
I think it is clear but broken. In particular the part about
indicating secure/non-secure transport.
The text relating to transport is applied to generally and needs clarifying.
Let's provide a specific goal:
For Yang notifications, there may be some desire for the information to be
sent across alternative transports, potentially with specific encodings.
draft-ietf-netconf-yang-push covers I2RS use cases wherein the data may be
sent via alternative transports. Should we have some sort of markup in the
Yang language to identify what transports might be utilized? What about
security requirements?
Obviously we can spell out transport security considerations as part of the
description clause within a notification. However, since a significant
amount of feedback has been given from individuals with a security
background that many objects we're likely to use in I2RS may be security
sensitive - but not all! - some way to indicate the sensitivity may be
required.
The motivation for this is that for insecure and high speed transports and
ecodings such as IPFIX (e.g.) it may be fine to expose some data (e.g.
interface statistics) but the same may not be true for other data and a
secured transport may be required.
...
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
