Subject: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 17 Aug 2016 07:54:38 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

== Section 3.2 ==

"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."

What kind of telemetry data is it that is of no potential interest to any
eavesdropper? This is not my area of expertise so I'm having a hard time
conceiving of what that could be. I'm also wondering, since I2RS agents
and clients will have to support secure transports anyway (and RESTCONF
can only be used over a secure transport), why can't they be used for all
transfers, instead of allowing this loophole in the name of telemetry,
which undoubtedly will end up being used or exploited for other data
transfers?

If the argument was that this loophole is needed for backwards
compatibility with insecure deployments of NETCONF or something like that
I think it would make more sense, but my impression from the text is that
those will have to be updated anyway to conform to the requirements in
this document.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In general I agree with Mirja that where other documents already provide
definitions, they should be referenced, not copied or summarized, in this
document. 

== Section 2.1 ==

Using "privacy" as a synonym for "confidentiality" is outmoded, I think,
given current understanding of the many other facets of privacy (see,
e.g., RFC 6793). I would suggest dropping the definition of data privacy
and just using the word confidentiality when that is what you mean.

== Section 2.2 ==

"The I2RS protocol exists as a higher-level protocol which may
      combine other protocols (NETCONF, RESTCONF, IPFIX and others)
      within a specific I2RS client-agent relationship with a specific
      trust for ephemeral configurations, event, tracing, actions, and
      data flow interactions."

Reading the provided definition of "trust," I'm not sure what "with a
specific trust for" means in the sentence above.

"The I2RS architecture document [I-D.ietf-i2rs-architecture]
      defines a secondary identity as the entity of some non-I2RS entity
      (e.g. application) which has requested a particular I2RS client
      perform an operation."
    
Per my comment above, I would suggest just referencing the definition
from the architecture document. The text above is circular ("the entity
of some ... entity") and conflates an identity with an identifier.

== Section 3.1 ==

Agree with Mirja that this section is superfluous.

== Section 3.3 ==

Since the normative recommendation here isn't to be enforced by the
protocol, why is it SHOULD rather than MUST? Same question applies to
SEC-REQ-17.

== Section 3.5 ==

Is the omission of normative language from Sec-REQ-20 purposeful?

---

From: Alia Atlas <[email-masked]>
Date: Wed, 17 Aug 2016 11:07:16 -0400

Hi Alissa,

> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-

Data coming from a router can come from many different line-cards and
processors.
The line-cards that may be providing the data are not going to be
supporting the
secure transports anyway.  A goal is to allow easy distribution of
streaming data
and event notifications.  As for what type of data, as far as I know,
currently IPFIX
streams telemetry data without integrity much less authorization protection.

There are existing deployments that use gRPC now for streaming telemetry
data.

 Regards,
Alia

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 17 Aug 2016 13:02:09 -0400

Hi Alia,

> On Aug 17, 2016, at 11:07 AM, Alia Atlas <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>
> 
> 
> 
> Data coming from a router can come from many different line-cards and processors.
> The line-cards that may be providing the data are not going to be supporting the 
> secure transports anyway. 

Will they also not be supporting the I2RS protocol then, given the requirement for support of a secure transport?

> A goal is to allow easy distribution of streaming data
> and event notifications.  As for what type of data, as far as I know, currently IPFIX 

What I’m questioning is the choice to extend that model to cases where a third-party controller or application is one endpoint of the data exchange, which is what I thought was part of the motivation for I2RS (happy to be corrected though).

> 
> There are existing deployments that use gRPC now for streaming telemetry data.

Ok. So is the implication that the requirements here are needed for backwards compatability with those deployments?

Thanks,
Alissa

---

From: [email-masked]
Date: Wed, 17 Aug 2016 18:24:22 +0000

Hiya, 

I'm on vacation so won't be balloting this week and I only had a quick flick of this, but if I'd had time for a proper read I think I'd be asking how realistic are these requirements, possibly as a discuss ballot. If someone wanted to hit defer and blame me (sorry I don't have the right devices with me to do that) that'd be good. But if this draft is  time-critical for the WG then please ignore the above. 

S.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 19:58:06 -0400

Stephen: 

We have discussed these requirements with the NETCONF/RESTCONF group as part of the process.  This WG group did not raise any issues of about the requirements not being realistic. 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 17, 2016 2:24 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)

Hiya, 

S. 

On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote:
> > When responding, please keep the subject line intact and reply to 
> > all email addresses included in the To and CC lines. (Feel free to 
> > cut this introductory paragraph, however.)
> > 
> > 
> > Please refer to 
> > https://www.ietf.org/iesg/statement/discuss-criteria.html 
> > <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-
> > requirements/>
> > 
> > 
> > 
> > What kind of telemetry data is it that is of no potential interest 
> > to any eavesdropper? This is not my area of expertise so I'm having 
> > a hard time conceiving of what that could be. I'm also wondering, 
> > since I2RS agents and clients will have to support secure transports 
> > anyway (and RESTCONF can only be used over a secure transport), why 
> > can't they be used for all transfers, instead of allowing this 
> > loophole in the name of telemetry, which undoubtedly will end up 
> > being used or exploited for other data transfers?
> > 
> > compatibility with insecure deployments of NETCONF or something like 
> > that I think it would make more sense, but my impression from the 
> > text is that those will have to be updated anyway to conform to the 
> > requirements in this document.
> > 
> > supporting the secure transports anyway.
> 
> > A goal is to allow easy distribution of streaming data and event 
> > notifications.  As for what type of data, as far as I know, 
> > currently IPFIX streams telemetry data without integrity much less authorization protection.
> 
> > In general I agree with Mirja that where other documents already 
> > provide definitions, they should be referenced, not copied or 
> > summarized, in this document.
> > 
> > == Section 2.1 ==
> > 
> > Using "privacy" as a synonym for "confidentiality" is outmoded, I 
> > think, given current understanding of the many other facets of 
> > privacy (see, e.g., RFC 6793). I would suggest dropping the 
> > definition of data privacy and just using the word confidentiality when that is what you mean.
> > 
> > == Section 2.2 ==
> > 
> > Reading the provided definition of "trust," I'm not sure what "with 
> > a specific trust for" means in the sentence above.
> > 
> > Per my comment above, I would suggest just referencing the 
> > definition from the architecture document. The text above is 
> > circular ("the entity of some ... entity") and conflates an identity with an identifier.
> > 
> > == Section 3.1 ==
> > 
> > protocol, why is it SHOULD rather than MUST? Same question applies 
> > to SEC-REQ-17.
> > 
> > == Section 3.5 ==
> > 
_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:47:59 -0400

> I'm on vacation so won't be balloting this week and I only had a quick flick of this, but if I'd had time for a proper read I think I'd be asking how realistic are these requirements, possibly as a…

I hit the defer button for Stephen.  Alia doesn't want this to sit too
long, so we'll ave to be good about wrapping it up as there are other
groups waiting on it.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 09:51:13 -0400

Kathleen and Stephen: 

Can you tell me the reason for defer?  Alia will not be there in the next formal telechat - so no responsible AD will be there for the document.   

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Thursday, August 18, 2016 9:48 AM
To: Stephen Farrell
Cc: [email-masked]; Alissa Cooper; [email-masked]; Alia Atlas; [email-masked]; Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)

> I'm on vacation so won't be balloting this week and I only had a quick flick of this, but if I'd had time for a proper read I think I'd be asking how realistic are these requirements, possibly as a…

I hit the defer button for Stephen.  Alia doesn't want this to sit too long, so we'll ave to be good about wrapping it up as there are other groups waiting on it.

Thanks,
Kathleen

>> > <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security
>> > -requirements/>
>> >
>> >
>> >
>> > since I2RS agents and clients will have to support secure 
>> > transports anyway (and RESTCONF can only be used over a secure 
>> > transport), why can't they be used for all transfers, instead of 
>> > allowing this loophole in the name of telemetry, which undoubtedly 
>> > will end up being used or exploited for other data transfers?
>> >
>> > compatibility with insecure deployments of NETCONF or something 
>> > like that I think it would make more sense, but my impression from 
>> > the text is that those will have to be updated anyway to conform to 
>> > the requirements in this document.
>> >

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:57:49 -0400

> Can you tell me the reason for defer?  Alia will not be there in the next formal telechat - so no responsible AD will be there for the document.

Stephen is on vacation and can't read the draft, but would like to
read it.  I chatted with Alia on it and if Stephen can read it next
week to resolve any findings while Alia is not on vacation, this
should be fine on the next telechat as she could set the appropriate
action in place before the call (or before she leaves for vacation).

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 11:31:53 -0400

Thank you for letting me know the reasons and the schedule. I will make time next week to do additional changes.   I have a version-09 begun with Alvaro's comments.  Are there other changes I should include in version -09.txt?

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 9:58 AM
To: Susan Hares
Cc: Stephen Farrell; [email-masked]; Alissa Cooper; [email-masked]; Alia Atlas; [email-masked]; Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)

> Can you tell me the reason for defer?  Alia will not be there in the next formal telechat - so no responsible AD will be there for the document.

Stephen is on vacation and can't read the draft, but would like to read it.  I chatted with Alia on it and if Stephen can read it next week to resolve any findings while Alia is not on vacation, this should be fine on the next telechat as she could set the appropriate action in place before the call (or before she leaves for vacation).

Thanks,
Kathleen

> Cc: [email-masked]; Alissa Cooper; [email-masked]; Alia Atlas; 
> [email-masked]; Jeffrey Haas; 
> [email-masked]
> Subject: Re: [i2rs] Alissa Cooper's Discuss on 
> draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and 
> COMMENT)
>
>>> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security
>>> > -
>>> > requirements/
>>> > ------------------------------------------------------------------
>>> > -
>>> > ---
>>> > DISCUSS:
>>> > ------------------------------------------------------------------
>>> > -
>>> > ---
>>> >
>>> > == Section 3.2 ==
>>> >
>>> > to any eavesdropper? This is not my area of expertise so I'm 
>>> > having a hard time conceiving of what that could be. I'm also 
>>> > wondering, since I2RS agents and clients will have to support 
>>> > secure transports anyway (and RESTCONF can only be used over a 
>>> > secure transport), why can't they be used for all transfers, 
>>> > instead of allowing this loophole in the name of telemetry, which 
>>> > undoubtedly will end up being used or exploited for other data transfers?
>>> >
>>> > the text is that those will have to be updated anyway to conform 
>>> > to the requirements in this document.
>>> >
>>> > ------------------------------------------------------------------
>>> > -
>>> > ---
>>> > COMMENT:
>>> > ------------------------------------------------------------------
>>> > -
>>> > ---
>>> >
>>> > Reading the provided definition of "trust," I'm not sure what 
>>> > "with a specific trust for" means in the sentence above.
>>> >
>>> > Since the normative recommendation here isn't to be enforced by 
>>> > the protocol, why is it SHOULD rather than MUST? Same question 
>>> > applies to SEC-REQ-17.
>>> >
>>> > == Section 3.5 ==
>>> >

-- 

Best regards,
Kathleen