Re: [Isms] Moving into some design/architecture issuesofExtendedVACM

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

Hi -

> From: "Dave Nelson" <d.b.nelson at comcast.net>
> To: <isms at ietf.org>
> Sent: Tuesday, June 16, 2009 5:38 AM
> Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM
...
> The issue that seems to be most contentions is whether the securityName to
> groupName binding provided by RADIUS is persistent in the NAS after the
> session has ended.  While this is the way SNMP works it is not the way
> RADIUS works.  This is the root of the disagreement -- very different
> persistence models between RADIUS provisioning and SNMP provisioning.  Each
> camp naturally views the issues from their own experience base and comfort
> zone.
> 
> How do we resolve this?

I think it's helpful to break it down into the specific cases:

(1) a matching entry (identified by user name and security model) already 
      exists when the data from RADIUS arrives.

      This is the case that's been getting most of the attention in this discussion.
      It occurs when something gets provisioned both through SNMP and through
      radius.  I believe that in this case, the persistence should be in accordance
      with the row's StorageType, and that the most recently supplied group
      mapping should "win", with no mystical "reverting" of values.

(2) No matching entry exists when the data from RADIUS arrives.

      I think it is quite reasonable for such entries to have a very limited lifetime,
      and that upon expiration of that lifetime, they should evaporate, unless
      in the meantime a manager has stepped in and changed the StorageType
      from 'volatile' to something more permanent.

Now, I *think* a reasonable compromise is possible.  Under normal operational
conditions, it doesn't make much sense to provision vacmSecurityToGroupStorageType
to be volatile.  After all, the security administrator creating the entry would almost
certainly like it to survive the next reboot!  So, consider the following:

When the data arrives from RADIUS, check for a matching  vacmSecurityToGroupEntry.
If it exists and vacmSecurityToGroupStorageType is not readOnly:
Then
   update vacmGroupName with the data received from RADIUS
Else
   create an appropriate entry:
       using the supplied data for  vacmSecurityName, vacmSecurityModel,
       and vacmGroupName; 'volatile' for vacmSecurityToGroupStorageType,
       and 'active' for 'vacmSecurityToGroupStatus'

When the user's last session goes away (there may be multiple, overlapping
sessions, right?):
If there is a matching  vacmSecurityToGroupEntry (it's possible that creation
failed due to system resource exhaustion, but that is a pathological corner case)
Then
   if the entry's vacmSecurityToGroupStorageType is 'volatile'
   Then set vacmSecurityToGroupStatus to 'destroy'

I think this satisfies fairly well everyone's requirements, doesn't change VACM
one bit, produces no "surprising" results and is really really simple.

Randy