+ more... > From: Ben Campbell, May 05, 2016 5:58 PM > > Hi Eric, same here. > > On 5 May 2016, at 8:18, Eric Voit (evoit) wrote: > > > Hi Ben > > > > Thanks, more in-line... > > > >> From: Ben Campbell, May 05, 2016 12:12 AM > >> > > [...] > > >>>> ------------------------------------------------------------------- > >>>> --- > >>>> 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-req > > uirements/ > > > > 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. > > (See my comments to Susan.) My concern here is that there are a assumptions > about the security properties of the environment that need to be explicit. You > don't have to restate everything, but pointing to those documents would help.
I have just inserted the following text into the start of Section 4.2.4.: "It is possible for updates coming from a Subscription Service to be pushed over different types of transports. Good deployment practices will bind the Subscription Service into secure, encrypted transport layer mechanisms. For example if NETCONF is used then RFC5523 would be a valid option to secure the transported information." Do this meet your intent? > But there's still a fundemental conflict between the idea that this mechanism > should be useful beyond the i2rs context, and the assumption of i2rs security > mechanisms. I see no conflict because I2RS security mechanisms apply to I2RS deployments. Existing transport security mechanisms can be applied for other deployment types. This hopefully is highlighted/supported via the text just proposed above. >From day 1 we have been aggregating requirements from beyond the I2RS domain. > Discussion across ADs for Routing and Ops and with multiple WG chairs have >pointed us to an aggregated requirements draft. These requirements are >useful for I2RS deployment cases. These requirements are useful for other use >cases as well. This draft has been reviewed with NETCONF and NETMOD, and the >NETCONF has draft-ietf-netconf-yang-push (not bound to I2RS protocols) based >on these requirements. > >>>> - 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. > > I accept that--but if that is the case, it doesn't seem wise for the > requirements to assume something is not a problem because it's not a > problem for a particular solution. In the NETCONF WG we are doing our very best to decouple the subscription establishment and maintenance technology draft from the underlying transport drafts. This is being well received; independent drafts for NETCONF, RESTCONF/HTTP subscription transport are on a path to adoption. Broadband Forum members attending IETF96 have suggested we consider IPFIX transport. Others have suggested COAP transport. Still others are thinking about how to integrate it into GPB/GRPC. By avoiding transport specifics, the Subscription Service becomes more widely applicable. > > > >>> > >>> 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). > > > > Hmm. I infer from that that requirements about how Updates are carried > (as opposed to when and to whom they are carried) are not in scope here? > But that still ties back to whether this is expected to be a general > mechanism, vs just an i2rs or netconf mechanism. Hopefully this is addressed above. > >>> > >>>> ---------------------------------------------------------------------- > >>>> 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. > > Ah, there lies the confusion. I interpreted the "(if supported)" part to > be about whether the dampening period was supported, not about whether > on-change was supported. > > I suggest something to the effect of: > OLD > The dampening period, for on-change update policy (if supported) > NEW > The on-change policy dampening period (if the on-change policy is > supported). Makes sense. Updated per your suggestion in the '-08' working copy. Eric > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
