Re: Notifications with config change

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

So, I'm confused by your response because it doesn't seem
to address whether or not there is a benefit that exceeds
the cost from "providing a notification channel that is
created and shares fate with a session that includes a
configuration channel".

As regards to "role based management", it is one,
but not the only approach for implementing authorizations.
That is, I don't see it as a requirement, and instead
see it a one potential solution in managing authorizations.

(see inline comment below)
On Wed, 29 Mar 2006, Cridlig Vincent wrote:
> > A second related issue is that the authorization to modify
> > the notification delivery part of the configuration is
> > an upgrade in capabilities of a configuration application
> > which could be abused. In very small systems, the 
> > capability to view and/or modify config is all or
> > nothing. The next step up in granularity is separating
> > the config into the "admin part" and the "operational
> > part", and then having separate apps (and authorized
> > identities) for managing the admin and operational
> > parts of the config. (The admin part determines the
> > list of authorized identities and what each is
> > authorized to do, including receive notifications.
> > To receive notifications the following must be
> > configured: the target address, credentials to use in
> > creating the session to deliver the notifications,
> > the filters for the session, and access to a log
> > in case the notifications can not be delivered.)
> > The next step up is dividing the config into
> > further pieces so that applications can be
> > restricted to modifying only the needed parts.
> >   
> This is where Role-Based Access Control comes into action.
> Dividing the config into further pieces is exactly the same as defining 
> a set of roles for identities (users or appplications), each role being 
> granted some permissions.
> When a user activates a role, he is allowed to update only a limited 
> part of the config, which helps a lot for reducing misconfiguration.
> 
> In your example, you would instead define a adminRole and an 
> operationalRole. OperationRole, for instance, would be granted the 
> permission to modify a specific subtree of the Netconf data model 
> related to operational configuration. adminRole would be allowed to 
> modify the security policy of the management interface (Netconf itself).
> A monitorRole would be granted the permission to receive notifications.
> And so on...
So, using role-based access control (which is one possible
approaches to specifying authorization) it doesn't seem to
eliminate the 1st and 3rd config changes, nor does it eliminate
an upgrade in authorization. I'm I messing something?

> 
> Vincent
> 
> > So, in summary, I believe that providing a notification
> > channel that is created and shares fate with a session
> > that includes a configuration channel is a desired
> > feature because:
> > 1) it eliminates what appear like two config changes
> > 2) it results in better system security
> >
> > Note that I realize that the above benefits come
> > with costs, and they include:
> > 1) an increase in complexity of the NETCONF protocol
> > 2) a change in mindset of existing developers and
> >    users of existing approachs
> >
> > I believe that the benefits far exceed the costs.
> >
> > Regards,
> > /david t. perkins   

Regards,
/david t. perkins


--
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/>