Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

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:[e-mail]]
> Sent: Friday, May 13, 2016 11:26 AM
> To: Susan Hares; Ben Campbell; Alia Atlas ([e-mail])
> Cc: The IESG; [e-mail]; 
> [e-mail]; [e-mail]
> 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:[e-mail]]
> Sent: Friday, May 06, 2016 7:09 PM
> To: Ben Campbell
> Cc: Eric Voit (evoit); The IESG; [e-mail]; 
> [e-mail]; [e-mail]
> 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 <[e-mail]>
>
> Date: 5/6/2016 2:38 PM (GMT-06:00)
>
> To: Susan Hares <[e-mail]>
>
> Cc: Eric Voit <[e-mail]>, The IESG <[e-mail]>, 
> [e-mail], [e-mail], 
> [e-mail]
>
> 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:[e-mail]]
>> Sent: Thursday, May 05, 2016 5:31 PM
>> To: Susan Hares
>> Cc: Eric Voit; The IESG; [e-mail];
>> [e-mail]; [e-mail]
>> 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:[e-mail]] On Behalf Of Eric Voit
>>> (evoit)
>>> Sent: Wednesday, May 04, 2016 7:25 PM
>>> To: Ben Campbell; The IESG
>>> Cc: [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]
>>> 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:[e-mail]> [e-mail]
>>>
>>>  <https://www.ietf.org/mailman/listinfo/i2rs>
>>> https://www.ietf.org/mailman/listinfo/i2rs