Subject: [Isms] VACM/RADIUS issue: counters

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Feb 2010 22:18:36 -0800

Hi -

The current i-d (draft-ietf-isms-radius-vacm-03.txt) contains
several counters.  Working through the elements of procedure,
I've come to the conclusion that they'd really not be much
help in the operational situations I've been able to think of.

To be even potentially useful, one would need to know for which
user / security model combination the error occurred.  In those
cases, the number of occurrances isn't as interesting as whether
and when the event occurred.  To me this means that if we bother
tracking these corner cases at all (and I'm NOT convinced that
they're worth tracking!) that Notifications, rather than counters
would be appropriate.  (A notification could carry the entry from
the extVacmSecurityToGroupTable, which would be all the interesting
stuff a security administrator would need to diagnose a problem.)
The corner case remaining is where memory allocation fails for
the extVacmSecurityToGroupTable.  Frankly, this case seems exceedingly
pathological.  I can't come up with a realistic recovery strategy that
a network manager might undertake in this case, and don't see the point
in counting it.  For the implementations I'm familiar with, if
internal memory is so tight that the extVacmSecurityToGroupTable
allocation would fail, there'd be serious doubt whether *any* response
at all would get out of the (sub)agent.

As a strawman position, I propose eliminating *all* the counters in
the MIB module.  If we find that they (or notifications) are useful
during early implementation efforts, we can add the ones with proven
utility at that time.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Feb 2010 08:25:03 +0100

On Fri, Feb 26, 2010 at 07:18:36AM +0100, Randy Presuhn wrote:

[...]
 
> during early implementation efforts, we can add the ones with proven

I am fine with the strawman position. However, it is important to note
that these counters track error situations during the processing of a
RADIUS message by the NAS, so normal SNMP error handling does not
apply and I guess this was the motivation to add these counters.

extVacmResourceError:

    What is common practice in RADIUS land if a NAS is being told to
    do something but fails to do so due to resource constraints? Am I
    right that specs tend to be silent about this and implementors
    simply use syslog?

extVacmNoPolicy

    Looks like the counter is ill defined. It is not an error to point
    to a non-existing access table in VACM; it is perfectly valid to
    do so to say "no access". The description in section 6.1.3 also
    does not seem to be consistent with the counter definition. I
    think both places benfit if the counter goes away.

extVacmSecurityNameConflict

    This could be a useful counter or event to report. However,
    creating a static entry can also be a means to (temporarily)
    disable the automatic creation of mappings, which would then lead
    to regular counter increments or notifications. That said, I am
    fine with the strategy of leaving the counter out until we have
    more implementation experience.

/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: "Randy Presuhn" <[email-masked]>
Date: Fri, 26 Feb 2010 00:10:25 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, February 25, 2010 11:25 PM
> Subject: Re: [Isms] VACM/RADIUS issue: counters
...
> apply and I guess this was the motivation to add these counters.

Though I'm starting to think that we really don't even need to mention
RADIUS message processing, but rather just session initiation / termination
indications from the secure transport model in question.  But that's another
discussion.

>     right that specs tend to be silent about this and implementors

That would make more sense - an implementation that hits this situation
is in such trouble that I wouldn't even count on syslog working terribly well.

>     think both places benfit if the counter goes away.

Strongly agree.  I think the VACM semantics for non-existant groups/policies
work out very well here.  We can't really distinguish this case from a policy which
only allows access to things that don't exist.  :-)
 
>     more implementation experience.

Ok, so unless someone really really wants them, I'll get rid of them.
It's easier to add such things to a clean-up EOP than it is to try to
clean up the EOP while keeping counters that may or may not be 
operationally justified. 

Randy

---

From: [email-masked]
Date: Fri, 26 Feb 2010 16:31:37 +0000 (UTC)

Please forgive the lack of message trimming. I'm at home with no power and email only via iPhone.

I think removing the error counters is a big mistake.  I'll elaborate when I can do so using a real keyboard. ;-)

----- Original Message -----
From: Juergen Schoenwaelder <[email-masked]>
To: Randy Presuhn <[email-masked]>
Cc: [email-masked]
Sent: Fri, 26 Feb 2010 07:25:03 +0000 (UTC)
Subject: Re: [Isms] VACM/RADIUS issue: counters

[...]

extVacmResourceError:

extVacmNoPolicy

/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/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 26 Feb 2010 12:14:31 -0800

Hi -

Here are all the events I can think of that someone
might conceivably find interesting.  These don't *exactly*
match the ones that were in previous versions of the draft,
but some are pretty close.

(1) radius server fails to provide a user/group mapping -

    Since, however, its possible that a suitable mapping
    already exists in VACM, this isn't necessarily an error.

    Even if it *is* an error, a counter by itself isn't useful.
    What would be needed would be the security model and security
    name.  Since the elements of procedure do not (currently)
    create an extVacmSecurityToGroupEntry in this case, we would need to
    add accessible-for-notify objects along with a notification
    definition to carry this information.

    If a security administrator has subscribed to this notification,
    what next?

(2) the security model / security name / session ID triple
    corresponds to an extVacmSecurityToGroupEntry which already exists.

    With RADIUS this would suggest an internal logic error, with
    some other AAA protocol it might (I'm imagining) be the result
    of the user of an existing session having been assiged to a
    different group while the session was up.  The most robust
    thing to do in this case seems to me to treat is an an update
    of the user/group mapping.

    In any case, once again a simple counter wouldn't provide enough
    information to be useful.  A notification could carry the information,
    but would beg the question of whether it should carry the old group,
    the new group, or both.

    If a security administrator has subscribed to this notification,
    what "recovery action" (if it is an error) would he/she take?

(3) insufficient memory to allocate a new extVacmSecurityToGroupEntry -

    Do we expect security administrators to poll this?  What recovery
    action would be possible?  In many implementations, several
    malloc() operations can happen in the course of processing an
    SNMP message, but we certainly *don't* treat all these possible
    points of failure/recovery as countable events.  Requiring a
    notification in this case would be even worse, because notification
    generation logic is almost certain to have greater malloc()
    requirements than an entry in the extVacmTable.

(4) the group name provided by RADIUS currently is not in use by the
    vacmAccessTable -

    Operationally, I don't see how this is any different from a
    security adminstrator creating a group called "NoAccessAllowed"
    with no corresponding entries in the vacmAccessTable.  In terms
    of how VACM functions, the results are exactly the same.

    If we did track this condition, once again it would be best conveyed
    in a notification, since any conceivable recovery action would need
    to know which user and which group was the problem.

    However, *if* we go down this path, wouldn't we also want to consider
    the case where, for example, due to a security administrator's updates
    to the vacmAccessTable, all the entries indexed by a particular group
    are deleted, even though they may have been present at the time the
    extVacmTableEntry was created?  I think this goes far beyond the
    point of diminishing returns.

(5) Insufficient memory to create / update vacmSecurityToGroupEntry -

    See (3) above.

(6) Session termination indication refers to a non-existent session -

    A notification would be the appropriate vehicle for this, though
    it would require adding some accessible-for-notify objects to
    carry the information.

    I can't imagine what a security administrator could do to recover
    from this kind of internal logic error, except perhaps for cycling power.

(7) No vacmSecurityToGroupEntry exists corresponding to the
    extVacmSecurityToGroupEntry which has just been deleted -

    This could happen, for example, when a security administrator has
    deleted the vacmSecurityToGroupEntry in question.

    A notification would be the sensible vehicle for this.  Since
    the extVacmSecurityToGroupEntry in question would already
    have been deleted by the time this condition is detected,
    we'd need to add accessible-for-notify objects to report it.

    I have no idea what meaningful action a security administrator
    could take upon receipt of this notification, other than perhaps
    to make sure that it was indeed one of his/her authorized
    colleagues or applications that deleted the entry in question.

As a technical contributor, I remain unconvinced that any of these
would be worth the specification or implementation effort.

As an editor, I'll happily put back or add whatever the WG gets
consensus on.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 26 Feb 2010 13:57:47 -0800

Hi -

> From: "Randy Presuhn" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, February 26, 2010 12:14 PM
...
...

Upon further refleciton...

As the elements of procedure are currently formulated, this situation
is indistinguishable from the case where the start-of-session indication
did not (for whatever reason) trigger the creation of an
extVacmIUserToGroupEntry.  If we *really* care about distinguishing
this case, we'd need a extVacmUserToGroupEntry corresponding to
*every* start-of-session indication, including those providing
no (or a zero-length) group mapping.  Doing so could *slightly*
simplify the elements of procedure, but whether we do so or not,
I remain unconvinced that this case is worth tracking.

Randy