[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: access control on the <eventStreams> data model

Randy Presuhn wrote:

Hi -


From: "Andy Bierman" <ietf@andybierman.com>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Thursday, July 12, 2007 1:09 PM
Subject: access control on the <eventStreams> data model

...

It is not even clear that access control "by stream" even
makes any sense.  Access control by namespace and element name
within the data stream makes sense.  What if the same data
can appear in multiple streams?  It is also more robust
to simply exclude restricted data from the particular subscription,
rather than reject the entire subscription, because the manager
has access to most (but not all) of the possible data that
could be generated in a stream.  This is how access control
works in SNMP.  If you to a getnext or getbulk, it skips restricted data,
rather than rejecting the PDU with an error.

....

But, FWIW, that's not how access control for notifications works in SNMP.
RFC 3413 3.3 (2)


Do you mean para 2:

   Notification originator applications require a mechanism for
   identifying the management targets to which notifications should be
   sent.  The particular mechanism used is implementation dependent.
   However, if an implementation makes the configuration of management
   targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module
   described in this document.

I think you mean para 4, point 2:

   (2) The appropriate set of variable-bindings is retrieved from local
       MIB instrumentation within the relevant MIB view.  The relevant
       MIB view is determined by the securityLevel, securityModel,
       contextName, and securityName of the management target.  To
       determine whether a particular object instance is within the
       relevant MIB view, the isAccessAllowed abstract service interface
       is used, in the same manner as described in the preceding
       section, except that the viewType indicates a Notification-Class
       operation.  If the statusInformation returned by isAccessAllowed
       does not indicate accessAllowed, the notification is not sent to
       the management target.

The difference seems to be that (on a PER-NOTIFICATION basis)
the entire PDU is dropped if any data within it is restricted.
This is fine -- easier on the agent than pruning the restricted data
and sending the rest.

But this is much different than refusing to let the manager see
the name of the stream or rejecting the <create-subscription>
because individual notifications may not be delivered.



Randy


Andy




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>





--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>