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.