Re: [i2rs] I2RS Requriements - secure transfer

["Joel M. Halpern" <[e-mail]>]

All I was saying was that we as I2RS should focus on our requirement 
that it be possible to ship some data in a non-secure transport.  While 
I am tempted to argue against the requirement, it is the WG consensus, 
so it stands.

But when it comes to declaring requirements on marking which pieces of 
data may be shipped insecurely, and specifically marking that in AYNG, I 
think we are overstating the requirement.

Yours,
Joel

On 5/31/16 5:06 PM, Jeffrey Haas wrote:
> Joel,
>
> On Tue, May 31, 2016 at 04:17:50PM -0400, Joel M. Halpern wrote:
>> 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.
>
> The requirements have been getting written in a very proscriptive manner for
> the cases when security *is* required.
>
> We have had numerous discussions about other transports, which *might not*
> be secured.
>
> If your argument is that because we MUST support the secured cases that we
> don't need to cover the insecure cases, I strongly disagree.
>
>> I don't think I2RS cares what granularity this is marked at.
>
> I2RS doesn't give a darn.  Models and security folk reviewing the models do.
>
>> So lets not state a requirement on it?
>
> Let's not try to brush it off.
>
>> 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.
>
> Please try to have paid attention to the discussion the last two years about
> pub-sub mechanisms for telemtry data.  We have more than one vendor which
> has implemented some form of telemetry state coverable by yang modeling with
> alternate presentation or transport layers.  The most common example
> regularly cited has been GRPC with protobufs encoding. Discussion has
> happened in-hallway, on-list and between vendors about the potential
> programmatic mapping layers between things like protobufs, thrift and even
> IPFIX and yang although to my knowledge only protobufs and thrift had gotten
> more than a smattering of attention.
>
>> 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.
>
> IMO, calling it an "I2RS protocol" was mistaken.  The minute we decided we
> were going to attempt to leverage existing mechanisms such as netconf and
> restconf, the framing should have simply been "extensions to support i2rs
> cases".
>
> If netconf proved intransigent against the changes in question, it was
> likely at some point that the vendor set implementing i2rs mechanisms would
> eventually chosen to have forked netconf protocol behaviors to support their
> code and use cases for ephemeral state.  Thus far, it appears that each has
> chosen to stay with their own internal forms of ephemeral configuration and
> avoid exposing netconf mappings until these issues have resolved.
>
> -- Jeff
>
>