Subject: Re: [Isms] [IETFMIBS] Objects and side-effects

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 10:31:53 -0700

Hi -

Glenn wrote
...
> > >> Now, if the table-1 update is happening automatically, (every time
> > >> a start/stop indication arrives e.g. from RADIUS) as opposed to
> > >> being carried out by an Operator/NMS, the Operator/NMS will have no
> > >> way to tell that something is not working.
> > >> This will mean that though the RADIUS system lowered the privileges
> > >> of the principal the corresponding vacmAaaSecurityToGroupEntry will
> > >> retain the old values and this error condition will not be detectable
> > >> by an NMS or by any means.
> > >> Will this be OK?
...

We worked through the possible cases at some length on the isms WG
mailing list.  Keep in mind that the aaa/vacm table reflects what's going
on in aaa-land, and the vacm tables reflect the state of the vacm configuration.
Here are the cases I think you're concerned about.

A) indication arrives, conditions are not satisfied for the creation of
     an entry in vacmAaaSecurityToGroupTable.  Nothing happens -
     whether the corresponding session gets access is not affected
     by this.  Existing VACM configuration (and the decision of other
     parts of the implementation whether to authorize the session)
     prevail.

B) indication arrives, conditions are satisfied for the creation of an
     entry in vacmAaaSecurityToGroupTable, but conditions are not
     satisfied for an update of the corresponding vacmGroupName.
     Nothing happens - existing VACM configuration prevails.

C) indication arrives, conditions are satisfied for the creation of an
     entry in vacmAaaSecurityToGroupTable, but there is no corresponding
     entry in the vacmSecurityToGroupTable, and for whatever reason the
     implementation fails to create an entry in the vacmSecurityToGroupTable.
     The only way I can see this pathological condition occuring is if an
      implementation encounters an internal logic error or runs out of memory.
      In either case, there's really not much one can reasonably expect in the
      way of recovery via a management interface.  In this case, the result
      would that an entry would exist in the vacmAaaSecurityToGroupTable,
      reflecting the state of AAA-land, and the vacmSecurityToGroupTable
      would be unmodified, reflecting the state of VACM.  The net result is
      no different from if creation of the vacmSecurityToGroupEntry had
      succeeded, and a security administrator had subsequently deleted that
      entry via SNMP.  In short, the existing VACM configuration prevails.
      We deliberately remained silent on whether the session would continue
      or be terminated - neither case would grant access where it would be
      denied by the existing specifications.

On the isms  mailing list, we discussed the possibility of defining notifications for
some of these error conditions, worked out in considerably greater detail.
We opted to *not* put these in the MIB, awaiting operational experience.
For me the most convincing arguments against the notifications are:

  (1) if creation of a vacmSecurityToGroupEntry is failing due to lack
        of memory, it's unlikely that an implementation will have the (much greater)
        memory resources needed to create, filter, and send a notification.

  (2) for some of the error conditions considered, the network-wide scaling
       properties are worrisome.  Consider the family of cases where the
       VACM policy and AAA policy are (temporarily) out-of-sync.   In a very
       actively managed/monitored network with lots of short-lived sessions
       initiated by management systems, the resulting torrent of notifications
       could have the effect of a DoS attack on the security administrator.

  (3) we don't have any operational experience suggesting that this is a problem.
        I would suggest that trouble-shooting would have to proceed exactly as
        it does now when a user does not get the access writes (s)he expects,
        since it's still the VACM tables, and only the VACM tables, that control
        MIB access rights.

Does this answer your question?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 19:02:49 -0700

Hi -

> From: "Glenn M. Keeni" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, September 04, 2010 6:26 PM
> Subject: Re: [IETFMIBS] Objects and side-effects
...
> The separation of the AAA-land and VACM-land in the semantics of
> vacmAaaSecurityToGroupTable is not very clear and that is where the
> problem lies. You will notice that your interpretation differs from
> Juergen's for condition C. Your interpretation is that an
> entry will exist in table-1 (vacmAaaSecurityToGroupTable) but according
> to another interpretation the entry will not be created in table-1.
> [On 2010/09/04 18:10, Juergen Schoenwaelder wrote:]
> "In general, if you create a table entry and the row
> becomes active, the whole action must have been carried out
> successfully. It does not matter whether another MIB table is involved
> or any other resource of the managed device."
> [I interpret "whole action" to denote
>    - creation of entry in table-1 vacmAaaSecurityToGroupTable and
>    - side-effects in table-2 vacmSecurityToGroupTable.]

>From the wording of Juegren's response, I believe he was talking about
general principles of row creation via SNMP (using, e.g., RowStatus),
rather than a case where we are modeling system elements, where
changes to one system element may have consequences for some other
system element, and both are visible to management.

> It gets even more tricky with updates and deletes. With the
> success/failure in carrying out the side-effects muddying the table,
> we cannot tell what an entry in vacmAaaSecurityToGroupTable and its
> columns are supposed to mean/convey. We do not know whether it
> reflects AAA-land situation or VACM-land problems.

No.  There is nothing that one can do to the VACM configuration that
can cause the information in vacmAaaSecurityToGroupTable to change.
What text in the document would lead someone to conclude otherwise?

> If we made it abundantly clear that vacmAaaSecurityToGroupTable
> reflects AAA-land, specifically, the values received from the
> "indications",

I think the current text is clear.  Where does it even suggest that
something might propagate backwards from VACM into the
vacmAaaSecurityToGroupTable?

> and clarified that side-effects in VACM-land may or
> may not have succeeded  (success in carrying out side-effects is NOT
> a MUST/REQUIRED item in the semantics of vacmAaaSecurityToGroupTable)
> then there will be less confusion/ambiguity.

If a specifications need to spell out all the things that are "NOT REQUIRED",
we will  never finish.

> I have browsed through the discussion on notifications on the mailing
> list archives. I agree with the conclusions - notifications are not a
> good engineering solution. I may have missed it, but I did not see any
> discussion on the effects potential errors in creation/update/deletion
> of vacmSecurityToGroupTable will have on the semantics/usability of the
> vacmAaaSecurityToGroupTable.
 
Because there are no such effects.  VACM says what its configuration is.
The aaaVacmSecurityToGroupTable says what's been received most recently
from AAA-land.  That's all there is to it.  To make it any more elaborate
will be counter-productive, in my opinion.

Randy