Hi Ben Thanks, more in-line...
> From: Ben Campbell, May 05, 2016 12:12 AM > > Hi, thanks for the response. Comments in line, with sections removed that do > not seem to need further discussion: > > > On 4 May 2016, at 18:24, Eric Voit (evoit) wrote: > > > 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? > > > > 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. > > Where do those requirements live now? I recall this draft mentioning > that support for multiple transports is required, but I don't recall > seeing anything about the required transport properties. (It's entirely > possible I missed it, or just forgot.) In Susan's email, she points out other I2RS documents with such requirements such as: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ The authors do hope that these subscription requirements will be applicable beyond I2RS protocols. Therefore decoupling from transport to the degree possible seemed wise. Therefore we didn't list some of the many documents which talk about ways to lock down existing and potential transports over which subscription updates might be pushed. These exist elsewhere. Example documents which could have been linked include: - RFC5539: NETCONF over Transport Layer Security - RFC6242: Using the NETCONF Protocol over Secure Shell - others relating to Restconf, HTTP, IPFIX, etc. So in summary, it seems duplicative to bind in transport security references here when these should be picked up when a transport protocol selection is made. But we can include if directed by the IESG. > > > > 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. > > That will likely resolve my concern, but there's not enough detail here > to judge. I will watch for the update. Update posted. > > > > > >> - 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. > > I think you are talking about solution, not requirements. If the > solution is already known, what is the purpose of publishing the > requirements? One technology solution is being worked in the NETCONF WG, but this is in flux. Other solutions which don't meet the majority of these requirements are being worked elsewhere (e.g., OC-Telemetry.yang). There is value in listing the requirements in of themselves. > > > > 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. > > I think my response to this will depend on the details you mention are > coming in 07. This gets back to the point above about trying to maximally decouple subscription establishment security (discussed in this document) with transport payload security (which we believe is best left to the transports themselves to reference). > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > > [...] > > > >> -- 4.2.2, third bullet: The previous section said dampening periods > >> MUST be > >> supported. > > > > Yes, but dampening is never for periodic subscriptions. > > The third bullet is about on-change updates, not periodic publication. > 4.2.1 says the service MUST support dampening for on-change updates. Yes, but on-change itself is as SHOULD. See the requirement: A Subscription Service SHOULD support the ability to subscribe to updates "on-change", i.e., whenever values of subscribed data objects change. IF on-change is supported, then dampening is a MUST. The requirement in question must be written in a way which handles implementations which don't support on-change. Eric > [...] _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
