Re: [Isms] Moving into some design / architectureissuesofExtendedVACM

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

Hi -

> From: "Dave Nelson" <d.b.nelson at comcast.net>
> To: <isms at ietf.org>
> Sent: Wednesday, June 10, 2009 12:38 PM
> Subject: Re: [Isms] Moving into some design / architectureissuesofExtendedVACM
...
> Yes, I see that.  As the default for a new group entry is no access, there
> is no security risk.  OTOH, what's the operational advantage of populating
> the tables with useless / erroneous group names?  Conversely, what's the
> disadvantage of simply ignoring any non-existing group names, and dismissing
> them as a mis-configuration?  You many, of course, want a counter of these
> someplace.

I think the disadvantage is that of introducing yet another special case.
There is no way to tell the difference between "useless," "eroneous,"
and "I got there before the configuration updated was pushed to that
particular node."  (Operationally, the user-group mapping will go out
before there is any guarantee that all nodes for which that policy will
be relevant have been updated to include that policy in their repertoire.)

If we distinguish this case with special handling and counters, do we want
to propagate an error back to RADIUS-land?  (We have no mechanism for
delivering any special indication to the SNMP conversation partner.) What
is the recovery strategy upon receipt of this error, and is it any different from
any other access-denied situation?

Randy