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-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.
(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.
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.
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.
Thanks, I saw that shortly after I sent this, but have not yet had time
to look at it. I will do so as soon as I can.
- 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 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.
----------------------------------------------------------------------
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).
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
