Re: [Netconf] notification access control

[Andy Bierman <andy at netconfcentral.com>]

Phil Shafer wrote:
> Andy Bierman writes:
> > 3.2, para 4:
> >    After generation of the <notification> element, access control is
> >    applied by the server.  If a session does not have permission to
> >    receive the <notification>, then it is discarded for that session,
> >    and processing of the internal event is completed for that session.
>
> > I will assume an implementation may silently prune
> > parts of the payload from the notification, due to access
> > control policy.  The notification MUST be dropped
> > if the <eventType> element would be filtered out,
> > in violation of the <notification> element schema.
>
> Yes, let's add this as an issue list for a future -bis, since an
> implementation should be able to prune inappropriate elements from
> the notification.
>
> Also we should repair the word "after" in the above text, since
> there isn't any explicit to generate the <notification> element at
> all if no one is permitted to receive the content.

yes -- I assume you mean the 'stream n' delivery in figure 2.
The replay (logging service) is given a copy of the event.
Delivery of replay notifications to a stream is no different
than live events.  (not shown in figure 2.)

Also, the 'filter' step in figure 2 is misleading.
ACM and filtering is not applied on the stream, but
independently, on each subscription (not shown).

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.)
We should want to make it as difficult as possible
to discover the access control policy in use on an agent.


> Thanks,
>  Phil

Andy