Subject: [IETFMIBS] Objects and side-effects

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 04 Sep 2010 17:57:40 +0900

Hi,
  This is in the context of draft-ietf-isms-radius-vacm-10.txt
that I am reviewing. But the concern is generic.

   If creation/update/deletion of an entry in table-1
(of abc-MIB) implies creation/update of an entry in table-2
(of def-MIB)

  a. can we assume that an implementation
     will guarantee that creation/update/deletion
     of an entry in table-1 will ensure that
     corresponding creation/update/deletion
     of an entry in table-2 will be carried out
     and successfully?
  b. if the answer to (a) above is "yes" then I will
     rest.
     if the answer is anything other that "yes" then
     it will seem automatic that an indication
     be made available and set in the entry of table-1
     that will say that it is a "correct entry" (in
     the sense that it does live up to the declared
     semantics of entries in Table-1) if and only if
     all the creation/update/deletions in table-2 have
     been successfully carried out.

Please let me have your opinions please.

Glenn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Sep 2010 11:10:26 +0200

> Please let me have your opinions please.

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 04 Sep 2010 19:52:30 +0900

> matter whether another MIB table is involved or any other resource of
That sounds reasonable for the creation case. It actually goes along
track (a) above. And basically what we are saying is that the very fact
that the row is created implies that all the conditions (including
side-effects) are are met. But for update and delete- as far as the
table-1 is concerned -
       - if all side-effects are met (corresponding
            entry-12 is updated/deleted in table-2 etc.)
            entry-11 is updated/deleted in table-1
          else
            entry-11 will not be updated/deleted.

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?

Glenn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Sep 2010 13:29:49 +0200

> by an NMS or by any means.

I can't follow you. I fail to see the implementation issue you are
seeing.

/js

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 04 Sep 2010 23:52:05 +0900

> I can't follow you. I fail to see the implementation issue you are
I will try again. We have entry-11 in table-1 and entry-12 in table-2.
The semantics require that 'on the arrival of an "indication" entry-11
in table-1 (of abc-MIB) will be updated/deleted and entry-12 in
table-2 (of def-MIB) will be updated/deleted'.

The implementation logic for update and deletion will be
I-Logic:
         - if all side-effects are met (corresponding
              entry-12 could be updated/deleted in table-2 etc.)
              entry-11 is updated/deleted in table-1
            else
              entry-11 will not be updated/deleted.
Question:
A. Is I-Logic correct ?
   If yes, then we may have entries in the table that do not
   meet the semantics of the table. Remember, the semantics
   require the entries to be updated/deleted depending on
   the "indication" that arrives. [Effectively, we will not
   be sure about how to interpret an entry in table-1. E.g.
   Is a value in the entry the value from the latest
   "indication" or is it the value from the earlier
   "indication" because the update was not carried out as
    the corresponding side-effects could not be effected.]

B. If I-Logic is not correct then what is an implementer expected
   to do in such cases?

Does that help?

Glenn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Sep 2010 17:45:46 +0200

> B. If I-Logic is not correct then what is an implementer expected

No. SNMP sets are as simultaneous. There can be concurrent sets.  SNMP
sets that fail do not cause changes. And SNMP in general often mixes
config semantics with operational state semantics and operational
state can change anytime.

/js

---

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

Hi -

Glenn wrote
...
> > >> by an NMS or by any means.
...

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: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 05 Sep 2010 09:30:11 +0900

> state can change anytime.
OK. I was not sufficiently clear. In the problem statement above I
stated
" 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, ..."
Here "happening automatically,.. as opposed to  being carried out by
      an Operator/NMS" means that it is probably NOT being done by SNMP
      sets."
To restate, the update/deletion in table-1 is required by the defined
semantics of table-1 and is left to the implementation. That leads to
the contradiction. We will have entries in table-1 which should have
been updated/deleted according to semantics, but could not be updated/
deleted because corresponding entry in table-2 could not be updated/
deleted. The entry in table-1 will not have any consistent meaning.

What can we say about an entry in table-1
a. It reflects the actual values as obtained from "indication" ?
b. It does not reflect the actual values as the corresponding update
   could not be carried out in table-2 ?
c. The entry was actually meant to be deleted - but it is there
   because the corresponding entry in table-2 could not be deleted.?

That seems to be a problem. No?

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 05 Sep 2010 10:26:23 +0900

Hi,
> Does this answer your question?
Yes- partly. The AAA-land and VACM-land concepts make it easier to
discuss this issue.
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.]

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.
If we made it abundantly clear that vacmAaaSecurityToGroupTable
reflects AAA-land, specifically, the values received from the
"indications", 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.

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.

Glenn

---

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
...

>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.

> 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?

> "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

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 5 Sep 2010 06:44:37 +0200

> vacmAaaSecurityToGroupTable.

I am still confused.

Since you are having an issue with the VACM AAA MIB module, please
tell me a concrete example (that is a sequence of steps that must be
carried out) demonstrating how the problem occurs. Abstract discussions
do not help at this point in time.

/js

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 05 Sep 2010 16:06:52 +0900

Hi,
  Please see inline.
On 2010/09/05 11:02, Randy Presuhn wrote:
> Hi -
> 
>> From: "Glenn M. Keeni"<[email-masked]>
>> To:<[email-masked]>
Depends on the interpretation of the text in the document which now
seems to say in Section 7.
   On receipt of indication
      a. create/update/delete entry in vacmAaaSecurityToGroupTable
      b. create/update/delete entry in vacmSecurityToGroupTable
It does say after (a) do (b) from which one will infer (b) will not
be attempted if (a) fails. But it does not say what will be the effect
if (b) fails. There are 2 choices there-
      b-1. if (b) fails - rollback changes in (a)
      b-2. if (b) fails - do not rollback changes done in (a).
The above comment follows from the assumption that b-1 is the correct
action.

>From the mail-conversation it is now clear that  b-2 is intended action.
But it is not clear from the document that b-2 is the choice and b-1
is not. It does not seem to be obvious to me. If I have missed it,
please point it out to me.
> If a specifications need to spell out all the things that are "NOT REQUIRED",
OK. Please tell me where a implementer can find what steps are REQUIRED
to process an "indication" what actions must be taken if those steps do
not succeed. i.e. how to select between possibilities b-1 and b-2 above.
> from AAA-land.  That's all there is to it.  
Right. I agree. It makes everything straight and simple. But this must
be in the document. If it is already there please give me the pointer.
> To make it any more elaborate

Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 5 Sep 2010 16:10:52 -0700

Hi -

> Sent: Sunday, September 05, 2010 12:06 AM
...
> please point it out to me.

If the document anywhere suggested b-1, then I would agree that there
was a problem to fix.  But I don't see any such suggestion. We can't
say "don't do this" for every single idea someone or other might pull
out of thin air.  We only need to make sure that what the document says
is correct, and that what it requires is sufficient to do the job.

> not succeed. i.e. how to select between possibilities b-1 and b-2 above.

No implementation-neutral actions are needed in such cases, so none
are specified.  Implementation strategy b-1 is NEVER mentioned or even
suggested, as far as I know, nor are b-3, b-4, ... b-N or whatever else
someone might be able to imagine. 

The WG recognizes that some of the pathological internal error cases (out of memory)
will require imeplementation-specific recovery.  This is already addressed in
the beginning of section 7 in a (to me self-evident) paragraph:

   There are various possible implementation-dependent error cases not
   spelled out here, such as running out of memory.  By their nature,
   recovery in such cases will be implementation-dependent.
   Implementors are advised to consider fail-safe strategies, e.g.,
   prematurely terminating access in preference to erroneously
   perpetuating access.

There's a real danger of over-specification in such corner cases.
I think it is not helpful to scatter "you don't need to do anything
else" here and there throughout the document.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 09 Sep 2010 08:06:16 +0900

> is correct, and that what it requires is sufficient to do the job.
Yes. The document does not anywhere suggest b-1. It does not suggest b-2
either. So the implementer has to make a choice here. That is the
problem that needs fixing.
> someone might be able to imagine.
Yes. But there are two paths b-1 and b-2. And the document is silent
about which path should be traversed by the implementation. Or, which
which path should not be traversed.
> else" here and there throughout the document.
This not a case of over specification. You don't need to say "you don't
need to do anything else". But, if there are multiple cases like b-1,
b-2 above, the document text must clearly specify which case is to be
followed in the implementation. No?

Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Sep 2010 16:29:00 -0700

Hi -

> Sent: Wednesday, September 08, 2010 4:06 PM
...
> followed in the implementation. No?

No.  Case b-2 *is* "you don't need to do anything else".  
There's nothing in the spec to suggest that implementors should
go through all the extra work of doing the (incorrect) b-1.

It would be sort of like telling someone, in the course of an explanation
of how to compute a square root, "don't take this opportunity to
compute the value of Pi."  We can't defend against folks doing pointless
or incorrect stuff that is not even hinted at by the specification, and I
think it is unreasonable to try to do so.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 09 Sep 2010 14:57:07 +0900

> think it is unreasonable to try to do so.
It is time we moved this thread of discussion from generic Objects and
side-effects in tables to the specific case of
draft-ietf-isms-radius-vacm-10.

I will take this discussion to the ISMS-list.

Glenn