Re: MIB

[Randy Presuhn <rpresuhn@dorothy.peer.com>]

Hi -

> Message-Id: <4.2.0.58.20000605092156.00966d30@avarice.inner.net>
> Date: Mon, 05 Jun 2000 09:50:02 -0400
> To: Jon Saperia <saperia@mediaone.net>
> From: RJ Atkinson <rja@inet.org>
> Subject: Re: MIB
> Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
>         Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>,
>         <Spencer.Giacalone@predictive.com>, <djoyal@nortelnetworks.com>,
>         <mibs@ops.ietf.org>
> In-Reply-To: <B5612185.1EC1%saperia@mediaone.net>
> References: <2413FED0DFE6D111B3F90008C7FA61FB078BE0E8@nl0006exch002u.nl.lucent.com>
...
> 	The original proposal was for DESCRIPTION text for a
> specific OID in the OSPF that said that if a particular OSPF implementation 
> did NOT implement SNMPv3, then a particular OID (one enabling OSPF 
> cryptographic authentication) would be MAX-ACCESS of READ-ONLY, 
> but that if the agent DID implement SNMPv3, then that OID would have 
> a MAX-ACCESS of READ-CREATE.

No, the MAX-ACCESS would still be READ-CREATE.  The MIN-ACCESS
for that implementation would be READ-ONLY.  Though it'd be
ok to state this in the object's DESCRIPTION, the place it
really belongs is in the MODULE-COMPLIANCE part of the MIB.

I'm not sure how I'd implement this, since in general the
implementor of the subagent for a particular protocol has
no way of knowing in advance whether the master agents
that implementation will communicate with will have SNMPv3
interfaces or not.

I think it would be much better to provide a MIN-ACCESS with
an appropriate explanation, and to give recommendations in
the security considerations section for how VACM would be
used to provide appropriate protection.

> 	In short, the original proposal was that the MAX-ACCESS would be 
> a function of what security mechanisms were implemented and
> hence were --AVAILABLE-- to the operator.  
...

This is not what MAX-ACCESS is for.

MIN-ACCESS is used to describe what an implementation
can "get away with" - in this case, "READ-ONLY" if the
implementor has some way of knowing that the code will
only be deployed in unsecured environments.

However, in general subagents don't know whether their master
agent is capable of providing these protections.  The access
decision function is in the master agent, not the subagent.
Pushing the access decision function into subagents would cause
a raft of complications regarding access to and propagation
of the access control lists themselves.  Likewise, subagents
don't in general know what management protocol was used for a
given request.  This is a way of avoiding configuration
management nightmares in case protocols evolve or new security
models or access control models are deployed.

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------