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

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

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: <isms at ietf.org>
> Sent: Monday, June 15, 2009 10:01 PM
> Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM
...
> you have the same probem if I as the security administrator change the
> VACM table and then RADIUS comes in and simply changes what I have
> carefully configured.

I don't think this is operationally a problem.

As a matter of sanity, we have to assume that what the security administrator
tells RADIUS to do is the same as what he wants the SNMP-alone policy to be.
If they're at odds, he's got a bigger problem than we can solve here.

So the cases we need to worry about are those where SNMP and RADIUS
policy updates get out of phase.  The case you describe is the worst case
that can happen with a sane adminstrator, so it's worth exploring.

Consider what a security administrator needs to do to effect a policy change:
  (1) he needs to tell the RADIUS servers about the change
  (2) he needs to tell the SNMP management infrastructure about the change

(1) is going to generally propagate faster than (2), particularly since
(2) isn't complete until ever single managed device in the administrative
domain has been updated.

Even in the case that  (2) happens for some node before the
RADIUS servers are notified of the policy change,
it will "heal" when the RADIUS server is finally updated
and that user needs access again.  Furthermore, this behaviour is
in line with the "RADIUS is always definitive" philosophy folks
have been arguing for.

This worst-case scenario is still more desirable than the failure
mode I described with the proposed "revert" behaviour.

> I tend to agree with Dave Nelson that having a
> single table modified by two different entities is likely asking for
> trouble. You might argue that the problem is really the conflict
> between RADIUS policy and the security administrator's policy. My
> counter argument to that is that if both would be in fine synchrony,
> we would not need the RADIUS interface in the first place.

No, demanding synchronization is unrealistic.  We need to assume
they'll be out of sync at least some of the time, but we also should
assume that it's operationally desirable for them to converge.
Consequently, the "dueling manager" scenarios fall under the
general rubric of "don't do that", and we only need to check through
the cases where things are temporarily out of sync to understand
the implications.  In those cases, as far as I can tell, nothing worse
happens than would occur if updates were slow to be propageted
to the RADIUS servers in the absence of SNMP-based policy
updates.

Randy