Subject: Re: Heads Up - New Notification Log MIB Draft

From: [email-masked]
Date: Thu, 17 Dec 1998 16:01:59 -0500

>Here we have a problem. The actual cost of using two strings rather
>than a single string to index the tables is pretty small compared to
>the nightmare of trying to change anything in SNMPv3. And since
>expressions and event triggers have a higher need to be protected and
>since the expression and the event MIBs are designed to support
>offloading processing of multiple management applications, I would
>argue that we better make the ownership obvious. RMON introduced the
>concept of OwnerStrings and it has some value. All we are doing now in
>DISMAN is to make sure the OwnerStrings can be used for view-based
>access control (which means they have to be part of the index).

I am also against adding a second SnmpAdminString to complement OwnerIndex.
128 subidentifiers is an absolute limit with respect to indexing. Using
more of this up
is painful. As it is now 128 is often not enough. It is also painful to
manually enter long instance IDs on a command line to issue an SNMP
operation. I don't like the fact that  we all are starting to add an
OwnerIndex to selected tables but can see the need.

The way I understand the SNMPv3 framework is that if VACM isn't sufficient
then a new
access method can be defined. So, if VACM doesn't provide sufficient access
control then
perhaps a new access method should be defined. I don't expect that this
will occur soon,
nor do I actually think that this is needed.

It seems to me that we are trying to decide how VACM can be enhanced by
defining MIB object(s) that should be added to certain tables without
having defined and have had approved a standard for this.  Shouldn't an
internet-draft (possibly a supplement to the  VACM RFC) be created that
explains how a MIB should be defined to address real access control? I
don't think that this is a problem unique to DISMAN.

Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Dec 1998 23:06:58 +0100

>>>>> wkenneth  writes:

wkenneth> I am also against adding a second SnmpAdminString to
wkenneth> complement OwnerIndex.  128 subidentifiers is an absolute
wkenneth> limit with respect to indexing. Using more of this up is
wkenneth> painful. As it is now 128 is often not enough. It is also
wkenneth> painful to manually enter long instance IDs on a command
wkenneth> line to issue an SNMP operation. I don't like the fact that
wkenneth> we all are starting to add an OwnerIndex to selected tables
wkenneth> but can see the need.

Just to be very clear on this: The difference between using
"structured names" as suggested by Bob and using explicit owner
strings and names is a single subidentifier. And if people start to
put a delimiting character between the owner part and the name part in
a "structured name" (and there are good reasons to do so - see the
DISMAN meeting minutes), the number of subidentifiers used is actually
identical.

wkenneth> The way I understand the SNMPv3 framework is that if VACM
wkenneth> isn't sufficient then a new access method can be
wkenneth> defined. So, if VACM doesn't provide sufficient access
wkenneth> control then perhaps a new access method should be
wkenneth> defined. I don't expect that this will occur soon, nor do I
wkenneth> actually think that this is needed.

VACM requires to have all relevant access control information in the
instance identifier. This is the real reason why we need long and
therefore expensive instance identifier. And given the way the SNMP
protocol works and how the typical SNMP agent implementation works, I
have doubts that we will find an acceptable solution for an ACM which
gets the information for an access control decision from a different
source (e.g. another column in a conceptual table) any time soon.
(People already find simple things like securityNames in multiple
groups to be too expensive. ;-)

wkenneth> It seems to me that we are trying to decide how VACM can be
wkenneth> enhanced by defining MIB object(s) that should be added to
wkenneth> certain tables without having defined and have had approved
wkenneth> a standard for this.  Shouldn't an internet-draft (possibly
wkenneth> a supplement to the VACM RFC) be created that explains how a
wkenneth> MIB should be defined to address real access control? I
wkenneth> don't think that this is a problem unique to DISMAN.

Right, this problem is not unique to DISMAN. We were the first to hit
this problem in a more general way because at least some of our MIBs
have much more interesting access control requirements than most of
the MIBs we currently have on the standards track. BTW, previous
DISMAN meetings were full of discussions on how to satisfy the DISMAN
security needs with the SNMPv3 tools we got. The fact that we are
still discussing this is a good indicator that a document which
explains the issue would be valuable. (But it looks like we do yet
have consensus what the answer in such a document should look like.)

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Bob Stewart <[email-masked]>
Date: Thu, 17 Dec 1998 17:22:24 -0500

>DISMAN meeting minutes), the number of subidentifiers used is actually

True, but the code to look up an object with two index objects is more
complicated than with one, so using two does put an extra burden on the agent.

	Bob