Re: [Netconf] notification access control
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netconf] notification access control



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.

> > 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)?)



/martin

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.