Hi Ben,
There is no issue with rewording to a requirement rather than an intro. The second sentence below has been changed to meet 2119. Some uses of this Subscription Service will push privacy-sensitive updates and metadata. For privacy-sensitive deployments, subscription information MUST be bound within secure, encrypted transport layer mechanisms. For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging privacy-sensitive deployment contexts as well. As an example, deployments based on [i2rs-usecase] would apply these requirements in conjunction with those documented within [i2rs-environment-security] and [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element. Eric > From: Ben Campbell, May 15, 2016 3:18 PM > > Hi Eric and Sue, > > Thanks for the change, and I think it's on the right track. But I notice most > of the > other requirements, in the security considerations section and in other > sections, > use 2119 keywords. Is there a reason not to do so here? Would it be reasonable > to say that any embodiment of these requirements MUST support a transport > that provides encryption and integrity protection, and such a transport MUST > be > used when carrying privacy-sensitive information? > > Thanks! > > Ben. > > > On 13 May 2016, at 10:49, Susan Hares wrote: > > > Eric: > > > > > > > > Thanks for jumping in and putting out text that resolves Ben’s > > comments. This text works for me with one addition. Add reference to > > the security environment draft. > > > > > > > > Sue > > > > > > > > From: Eric Voit (evoit) [mailto:[email protected]] > > Sent: Friday, May 13, 2016 11:26 AM > > To: Susan Hares; Ben Campbell; Alia Atlas > > ([email protected]<mailto:[email protected]>) > > Cc: The IESG; [email protected]<mailto:[email protected]>; > > [email protected]<mailto:[email protected]>; > > [email protected]<mailto:[email protected]> > > Subject: RE: [i2rs] Ben Campbell's Discuss on > > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > > > > > Hi Ben, > > > > > > > > I have added the text below as the lead-in to section 4.2.5. I > > believe this meets the intents of your suggestions below. > > > > > > > > Hi Susan & Alia, > > > > > > > > I have uploaded v08 of > > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > > > If Ben concurs with the text below, I am not aware of any remaining > > discuss items. > > > > > > > > Thanks everyone for your reviews, > > > > Eric, Alex, & Alberto > > > > > > 4.2.5. Security Requirements > > > > Some uses of this Subscription Service will push privacy-sensitive > > updates and metadata. Good deployment practices will bind this > > generated information within secure, encrypted transport layer > > mechanisms. For example if NETCONF is used as transport, then > > [RFC5539] would be a valid option to secure the transported > > information. The Subscription Service can also be used with > > emerging > > deployment contexts as well. As an example, deployments based on > > [i2rs-usecase] can apply these requirements in conjunction with > > those > > documented within [i2rs-protocol-security] to secure ephemeral > > state > > information being pushed from a Network Element. > > > > > > > > > > From: Susan Hares [mailto:[email protected]] > > Sent: Friday, May 06, 2016 7:09 PM > > To: Ben Campbell > > Cc: Eric Voit (evoit); The IESG; [email protected]<mailto:[email protected]>; > > [email protected]<mailto:[email protected]>; > > [email protected]<mailto:[email protected]> > > Subject: Re: [i2rs] Ben Campbell's Discuss on > > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > > > > > Ben: > > > > > > > > This is wise idea. I will suggest some text to Eric and you in the > > morning. > > > > > > > > Sue > > > > > > > > > > > > > > > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > > > > -------- Original message -------- > > > > From: Ben Campbell <[email protected]<mailto:[email protected]>> > > > > Date: 5/6/2016 2:38 PM (GMT-06:00) > > > > To: Susan Hares <[email protected]<mailto:[email protected]>> > > > > Cc: Eric Voit <[email protected]<mailto:[email protected]>>, The IESG > > <[email protected]<mailto:[email protected]>>, > > [email protected]<mailto:[email protected]>, > > [email protected]<mailto:[email protected]>, > > [email protected]<mailto:[email protected]> > > > > Subject: Re: [i2rs] Ben Campbell's Discuss on > > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > > > > > Hi Susan, > > > > To be clear, I do not object to the wider context per se. My concern > > is > > that the security and privacy requirements are left as implicit, based > > on the more narrow i2rs/netconf context. I only mentioned the > > potential > > of restricting the contextas one possible way forward; I am certainly > > not wedded to it. > > > > My suggestion for a way forward would be to document the high level > > security and privacy requirements in this document. IIUC, the larger > > context includes potentially unknown contexts, so some of this may > > need > > to be conditional. For example, language like the following might be > > helpful (this is just an example--I don't mean to say that it is true > > or > > applicable): > > > > "Some uses of this mechanism may carry privacy-sensitive > > information, > > or generate privacy-sensitive metadata through the subscription > > mechanism. In contexts where this is true, the following requirements > > apply..." > > > > It might also be reasonable to say that, for the context of i2rs, > > these > > requirements are documented in [references] and are expected to be > > fulfilled by the [transport and or protocol] > > > > Eric's email also suggested that the actual transport of data from the > > Yang datastore may be out of scope for these requirements. I don't > > object to that, either, as long as it is clear and explicit, although > > it > > would be good to point to where it is _in_ scope. > > > > Thanks! > > > > Ben. > > > > On 6 May 2016, at 1:06, Susan Hares wrote: > > > >> Ben: > >> > >> This is the first of the "re-use" management protocols. The > >> requirements > >> are set-up so that we can suggest additions to the NETCONF and > >> RESTCONF for > >> this first of I2RS. > >> > >> The I2RS ephemeral work, pub/sub, traceability, and security are > >> target at > >> the I2RS protocol definition with the I2RS use case. However, since > >> these > >> are general additions to NETCONF/RESTCONF, this work can be used > >> elsewhere. > >> > >> I think the text you are highlighting has this larger context. Now, > >> one of > >> the really important things to chat with Alia and Benoit is how do we > >> handle > >> the wider use case. Do we mention the wider context? > >> > >> The WG thought mentioning it was important. > >> > >> Sue > >> > >> -----Original Message----- > >> From: Ben Campbell [mailto:[email protected]] > >> Sent: Thursday, May 05, 2016 5:31 PM > >> To: Susan Hares > >> Cc: Eric Voit; The IESG; [email protected]<mailto:[email protected]>; > >> [email protected]<mailto:[email protected]>; > >> [email protected]<mailto:[email protected]> > >> Subject: Re: [i2rs] Ben Campbell's Discuss on > >> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > >> > >> On 5 May 2016, at 5:15, Susan Hares wrote: > >> > >>> Eric, Ben and IESG members: > >>> > >>> > >>> > >>> The pub/sub requirements are part of a 5 part requirements. May I > >>> quote > >>> from the shepherd's report: > >>> > >>> --------------------- > >>> > >>> The requirements for the first version of I2RS are: > >>> > >>> 1) model driven ephemeral state - that is data models that do not > >>> survive > >>> > >>> a software or hardware reboot. > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > >>> > >>> > >>> > >>> 2) a secure protocol - > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req > >>> uireme > >>> nts/ > >>> > >>> > >>> > >>> 3) traceability - ability to record interactions between I2RS > >>> elements > >>> > >>> (Client, Agent, Routing system) > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > >>> > >>> > >>> > >>> 4) notification publication via subscription > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > >>> > >>> > >>> > >>> 5) Protocol to pass Data for Analytics > >>> > >>> The first version of these requirements does not include a > >>> > >>> separate analytical protocol requirements as the simple use cases > >>> may > >>> > >>> pass information via query/poll or the notifications. > >>> > >>> > >>> > >>> The I2RS protocol exists in an secure environment described by: > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment- > >>> reqs/ > >>> > >>> > >>> > >>> ------------------------- > >>> > >>> > >>> > >>> Eric - Perhaps it would be good to point to: > >>> > >>> . draft-ietf-i2rs-protocol-security-requirements and > >>> > >>> . draft-ietf-i2rs-security-environment-reqs/ > >>> > >>> > >>> > >>> Ben - Can you tell me how the shepherd report could have been > >>> clearer? > >>> The > >>> I2rs protocol security requirements require: confidentiality, > >>> encryption, secure transport, protection against replay attack, > >>> protection against DDoS attack (if possible). > >> > >> I think my confusion lies in the fact that, while the shepherd's > >> writeup > >> styles this draft as part of the I2RS protocol requirements, the > >> draft > >> itself claims to describe requirements for a generally useful pub-sub > >> interface to a yang datastore. It's not clear to me how and when the > >> I2RS > >> protocol security requirements apply to it. If the described > >> interface > >> is > >> intended to be useful in contexts other than I2RS (and the draft > >> explicitly > >> sets that expectation in 2.2), it needs to talk more generally about > >> security and privacy. > >> > >> For example, it might make sense to say that certain security > >> requirements > >> apply in environments where the mechanism might carry privacy > >> sensitive > >> data, and then point to the i2rs requirements for when the mechanism > >> is used > >> in an I2RS context. > >> > >> A different approach might be to more tightly constrain this to i2rs > >> > >>> > >>> > >>> > >>> Ben - On opting in, once the receive accepts a transport connection > >>> from the I2RS server - how is this not an opt-in to receive data? > >>> What > >>> are you looking for? > >> > >> I guess that depends on the transport. The transport requirements say > >> the > >> mechanism has to work over multiple transports. The last paragraph in > >> 4.2.4 > >> says "In the case of connection-oriented transports..." which > >> suggests > >> that > >> non-connection-oriented transports are possible. > >> > >> Even with a connection-oriented transport, this may depend on how > >> connection-management is handled, and whether the receiver might be > >> receiving things it _wants_ to receive on the same transport. > >> > >>> > >>> > >>> > >>> Sue Hares > >>> > >>> (shepherd) > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: i2rs [mailto:[email protected]] On Behalf Of Eric Voit > >>> (evoit) > >>> Sent: Wednesday, May 04, 2016 7:25 PM > >>> To: Ben Campbell; The IESG > >>> Cc: [email protected]<mailto:[email protected]>; > >>> [email protected]<mailto:[email protected]>; > >>> [email protected]<mailto:[email protected]>; > >>> [email protected]<mailto:[email protected]> > >>> Subject: Re: [i2rs] Ben Campbell's Discuss on > >>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > >>> > >>> > >>> > >>> Hi Ben, > >>> > >>> > >>> > >>> Thanks for the comment. In-line.... > >>> > >>> > >>> > >>>> From: Ben Campbell, May 04, 2016 2:49 PM > >>> > >>>> ---------------------------------------------------------------------- > >>> > >>>> DISCUSS: > >>> > >>>> ---------------------------------------------------------------------- > >>> > >>>> > >>> > >>>> I have a couple of points I would like to discuss. Hopefully they > >>>> can > >>> > >>>> be resolved > >>> > >>>> easily: > >>> > >>>> > >>> > >>>> Are there really no requirements for privacy or integrity > >>>> protection? > >>> > >>>> Is there an expectation that this mechanism would ever carry > >>>> privacy > >>> > >>>> sensitive or otherwise sensitive information? > >>> > >>> > >>> > >>> [eric's comment: > >>> > >>> When the subscription is established dynamically via an existing > >>> transport > >>> session (which is expected to be the dominant case) we have the same > >>> expectations for Privacy and integrity as would be provided via a > >>> "GET" > >>> instead of a "PUSH" over the same transport. We could have > >>> replicated all > >>> these requirements, but that was seen as unnecessary and likely less > >>> secure > >>> than adopting existing mechanisms. > >>> > >>> > >>> > >>> When the Subscriber and Receiver are different, then the transport > >>> connection will have credentials passed as part of the > >>> establishment. > >>> These > >>> credentials will be used as a Security Grooming Filter just like the > >>> above > >>> case so that pushed objects will be excluded from an Update > >>> Notification as > >>> per the permissions of the Receiver. (I.e., this is identical > >>> behavior to > >>> the above.) As several people have had questions about this, the > >>> new v07 > >>> will make this explicit in the Security section. > >>> > >>> End of eric's comment] > >>> > >>> > >>> > >>> Sue: The transport provides for privacy, integrity protection. > >>> Most > >>> configuration in network boxes would need privacy. > >>> > >>> > >>> > >>>> - 4.2.5, 2nd to last paragraph: > >>> > >>>> I am surprised to find that, when the receiver is not the > >>>> subscriber, > >>> > >>>> that the receiver is expected to opt-out. It seems like some form > >>>> of > >>> > >>>> opt-in or affirmative consent would be needed here. > >>> > >>> > >>> > >>> The question really was how heavy-weight should the mechanism be. > >>> Transports been considering are all encrypted. So there is already > >>> a > >>> level > >>> of trust between the peers. And a target can always pull down the > >>> connection if there are issues. > >>> > >>> > >>> > >>> In addition, multicast transports are viable for some future cases. > >>> We > >>> didn't want mechanisms which complicated this type of interaction, > >>> especially in a world where dumb IoT devices may be involved. > >>> > >>> > >>> > >>> Sue: If the receiver accepts a secure transport set-up from the > >>> server, can > >>> you provide the reason why this is not an "opt-in" once it receives > >>> the > >>> connection from the I2RS agent? > >>> > >>> > >>> > >>> > >>> > >>>> ---------------------------------------------------------------------- > >>> > >>>> COMMENT: > >>> > >>>> ---------------------------------------------------------------------- > >>> > >>>> > >>> > >>>> - General: I support Stephen's DISCUSS > >>> > >>>> > >>> > >>>> -2.2: What is the real scope of this work? Is it expected to > >>>> supplant > >>> > >>>> the mentioned mechanisms? > >>> > >>> > >>> > >>> No. It is just showing that many specialized Push mechanism exist. > >>> This > >>> is not intended to supplant existing mechanisms, although perhaps it > >>> can > >>> help avoid future dedicated solutions. > >>> > >>>> - 2.3: "We need a new pub-sub > >>> > >>>> technology" > >>> > >>>> The shepherd write up mentioned a goal to use existing > >>>> technologies. > >>> > >>>> Is the point of this sentence to suggest that is not feasible? > >>> > >>> > >>> > >>> Existing technologies cannot meet all the requirements specified. > >>> There are > >>> technology drafts progressing in NETCONF which can. > >>> > >>> > >>> > >>>> - 4.1, 4th paragraph: > >>> > >>>> The MAY doesn't seem right--is this a statement of fact that the > >>> > >>>> subscriber may have to resubscribe, or a requirement of the form > >>>> that > >>> > >>>> the service MAY force the subscriber to resubscribe? (Be careful > >>>> with > >>> > >>>> MAYs in requirements language--they imply unexpected things. For > >>> > >>>> example, several requirements say a SUBSCRIBE MAY do something--do > >>> > >>>> those imply that the service MUST allow the subscriber to do it ?) > >>> > >>> > >>> > >>> Good point. Reworded in v07. > >>> > >>> > >>> > >>>> -- 4.2.2, third bullet: The previous section said dampening periods > >>> > >>>> MUST be supported. > >>> > >>> > >>> > >>> Yes, but dampening is never for periodic subscriptions. > >>> > >>>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means > >>>> to > >>> > >>>> change the what subtrees the subscription applies to, but could be > >>> > >>>> interpreted to change the subtrees themselves. > >>> > >>> > >>> > >>> Fixed > >>> > >>>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but > >>> > >>>> gave the subscriber a way to reconstruct the order fulfill this > >>> requirement? > >>> > >>> > >>> > >>> Yes, the timestamp within an update. But this requirement targets a > >>> specific object in a specific subscription. So there should be no > >>> issues. > >>> > >>>> Nits: > >>> > >>>> - The shepherd write up suggests this is standards track. The draft > >>> > >>>> and tracker both say informational. Please update the shepherd writ > >>>> up. > >>> > >>> > >>> > >>> Fixed > >>> > >>>> -3, last paragraph: What's the difference between a "Push" and an > >>> "Update"? > >>> > >>> > >>> > >>> Reworded > >>> > >>>> -4.1: A forward reference to the subscription QoS section would be > >>> helpful. > >>> > >>> > >>> > >>> Moved the requirement in question to 4.2.6. > >>> > >>>> -- Last paragraph, last sentence: Sentence doesn't parse. > >>> > >>> > >>> > >>> Fixed > >>> > >>>> > >>> > >>>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY > >>> > >>> > >>> > >>> Fixed > >>> > >>> Thanks again for the review! > >>> > >>> Eric > >>> > >>> _______________________________________________ > >>> > >>> i2rs mailing list > >>> > >>> <mailto:[email protected]> [email protected]<mailto:[email protected]> > >>> > >>> <https://www.ietf.org/mailman/listinfo/i2rs> > >>> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
