That works for me. I will clear the DISCUSS.
Thanks!
Ben.
On 16 May 2016, at 9:46, Eric Voit (evoit) wrote:
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:ev...@cisco.com]
Sent: Friday, May 13, 2016 11:26 AM
To: Susan Hares; Ben Campbell; Alia Atlas
(akat...@gmail.com<mailto:akat...@gmail.com>)
Cc: The IESG; i2rs@ietf.org<mailto:i2rs@ietf.org>;
draft-ietf-i2rs-pub-sub-requireme...@ietf.org<mailto:draft-ietf-i2rs-pub-sub-requireme...@ietf.org>;
i2rs-cha...@ietf.org<mailto:i2rs-cha...@ietf.org>
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:sha...@ndzh.com]
Sent: Friday, May 06, 2016 7:09 PM
To: Ben Campbell
Cc: Eric Voit (evoit); The IESG;
i2rs@ietf.org<mailto:i2rs@ietf.org>;
draft-ietf-i2rs-pub-sub-requireme...@ietf.org<mailto:draft-ietf-i2rs-pub-sub-requireme...@ietf.org>;
i2rs-cha...@ietf.org<mailto:i2rs-cha...@ietf.org>
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 <b...@nostrum.com<mailto:b...@nostrum.com>>
Date: 5/6/2016 2:38 PM (GMT-06:00)
To: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>
Cc: Eric Voit <ev...@cisco.com<mailto:ev...@cisco.com>>, The IESG
<i...@ietf.org<mailto:i...@ietf.org>>,
i2rs@ietf.org<mailto:i2rs@ietf.org>,
draft-ietf-i2rs-pub-sub-requireme...@ietf.org<mailto:draft-ietf-i2rs-pub-sub-requireme...@ietf.org>,
i2rs-cha...@ietf.org<mailto:i2rs-cha...@ietf.org>
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:b...@nostrum.com]
Sent: Thursday, May 05, 2016 5:31 PM
To: Susan Hares
Cc: Eric Voit; The IESG; i2rs@ietf.org<mailto:i2rs@ietf.org>;
draft-ietf-i2rs-pub-sub-requireme...@ietf.org<mailto:draft-ietf-i2rs-pub-sub-requireme...@ietf.org>;
i2rs-cha...@ietf.org<mailto:i2rs-cha...@ietf.org>
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:i2rs-boun...@ietf.org] On Behalf Of Eric Voit
(evoit)
Sent: Wednesday, May 04, 2016 7:25 PM
To: Ben Campbell; The IESG
Cc: i2rs@ietf.org<mailto:i2rs@ietf.org>;
draft-ietf-i2rs-pub-sub-requireme...@ietf.org<mailto:draft-ietf-i2rs-pub-sub-requireme...@ietf.org>;
i2rs-cha...@ietf.org<mailto:i2rs-cha...@ietf.org>;
sha...@ndzh.com<mailto:sha...@ndzh.com>
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:i2rs@ietf.org> i2rs@ietf.org<mailto:i2rs@ietf.org>
<https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
