Re: [Isms] Moving into some design / architecture issues of Extended VACM

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "kaushik" <kaushik at cisco.com>
> To: "Dave Nelson" <d.b.nelson at comcast.net>; <isms at ietf.org>
> Sent: Thursday, June 11, 2009 3:27 PM
> Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM
...
> The issue I have with this model is that we are using the RADIUS
> user-to-group mapping which is a temporal association valid for the duration
> of the session and provisioning a persistent piece of configuration on the
> SNMP engine. I am not sure the semantics match and this could create
> potential problems around whether the RADIUS server or SNMP engine is
> authoritative source for user-to-group mapping since entries can be added to
> the vacmSecurityToGroupTable without knowledge of the RADIUS server.

"Authoritative source"?  Whoever has the necessary access rights to update
the vacmSecurityToGroupTable is authoritative, as far as VACM is concerned,
and whatever the current configuration of VACM is will govern who can do what
to anything via SNMP.

The persistance of the information is governed by  vacmSecurityToGroupStorageType.
If the entry already exists, that's already been configured.  If a new entry needs to
be created, 'volatile' is the only type that makes sense.  Forcing persistence does
not make sense.

I think the crucial point is whether the information coming from the RADIUS server
is trusted as much as information coming from a security administrator.  If it is, then
updating vacmGroupName with the most recently received information makes sense.
If the RADIUS server is not trusted as much as a security administrator, then information
from it should not be used for making user/group mapping decisions.

It does *not* make sense for the value of vacmGroupName to "revert" upon termination
of the session or some other condition.  Consider the operational scenario where the
update of the RADIUS server is slightly out-of-phase with a VACM access control policy push.
Simple update of vacmGroupName will produce the correct answer.  Doing a "revert"
will result in vacmGroupName being *temporarily* updated via RADIUS to the correct value,
the SNMP push will walk on by, and then the "revert" will restore it to a now obsolete value.  Not good,
so to fix *that* you'd have to add additional state and require the push application to
write to objects that would appear to already have the correct value.  Yuck!

This isn't netconf.  This is SNMP.  Let's remember what the "S" is supposed to stand for.

Randy