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

["Eric Voit (evoit)" <[e-mail]>]

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:[e-mail]]

> > Sent: Friday, May 13, 2016 11:26 AM

> > To: Susan Hares; Ben Campbell; Alia Atlas ([e-mail]<mailto:[e-mail]>)

> > Cc: The IESG; [e-mail]<mailto:[e-mail]>;

> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>;

> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>

> >

> > Date: 5/6/2016 2:38 PM (GMT-06:00)

> >

> > To: Susan Hares <[e-mail]<mailto:[e-mail]>>

> >

> > Cc: Eric Voit <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>,

> > [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>,

> > [e-mail]<mailto:[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]<mailto:[e-mail]>;

> >> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>

> >>>

> >>>  <https://www.ietf.org/mailman/listinfo/i2rs>

> >>> https://www.ietf.org/mailman/listinfo/i2rs