Re: [Netconf] notification access control

[Andy Bierman <andy at netconfcentral.com>]

Martin Bjorklund wrote:
> Andy Bierman <andy at netconfcentral.com> wrote:
> > Martin Bjorklund wrote:
> > > Andy Bierman <andy at netconfcentral.com> wrote:
> > > > The all-or-nothing approach actually helps hackers.
> > > > If there is no filter, then any dropped notification
> > > > would stick out like a red flag, since it must have
> > > > contained some sensitive data. (This works just
> > > > by watching the traffic with wireshark, without
> > > > actually being able to read any of the packets.)
> > > How would a hacker know that a notification was *not* sent by watching
> > > the traffic?
> > by watching traffic patterns (when multiple subscriptions
> > are active).
>
> But you wouldn't know that the different subscriptions use the same
> filter.

true -- especially since the filter element is
getting removed from the ietf-netconf-state module.

> > > I don't care that much if the entire notif is dropped, or some element
> > > is pruned, but the current spec is pretty clear - the notification
> > > MUST be dropped.  So a 5277 compliant server cannot prune
> > > elements from the notifications.
> > I don't think the RFC says that anywhere.
> > There is just the vague text about granting
> > permission.  IMO, that meant that the manager
> > has permission to see the <eventType> element,
> > but it does not mean the entire payload is going
> > to be delivered, if ACM policy decides otherwise.
>
> Ok, I agree the text is vague.  But maybe this is good - it means that
> the ACM can define the behavior without a 5277bis.
>
> (Compare with 4741, it doesn't say what the result is if you do a
> <get> w/o a filter when you don't have read access to everything - do
> you get all data you're allowed to see (yes), or do you get an
> access-denied error (no)?)

For write access and exec access (invoke RPC method),
an access-denied error is generated.  For all read operations,
the data is just silently dropped.

Since there is no standard ACM, and assumptions are valid,
including these.


> /martin

Andy