Re: Special protocol contraints expressed in MIBs

[Kevin Lingle <klingle@cisco.com>]

bert,

you answered by questions.  thanks for the response.

kevin
"Wijnen, Bert (Bert)" wrote:
> 
> Nobody has yet answered, so let me comment a bit
> Inline
> 
> Bert
> 
> > -----Original Message-----
> > From: Kevin Lingle [mailto:klingle@cisco.com]
> > Sent: Thursday, February 14, 2002 6:07 PM
> > To: mibs@ops.ietf.org
> > Subject: Special protocol contraints expressed in MIBs
> >
> >
> > hi,
> >
> > is it illegal to define a mib such that you are constraining it's
> > implementors to use specific protocol constructs (not sure if that's
> > the righ term or not).
> >
> It is not clear to me what you mean.
> But for example, if you want to specify a MIB that has only 64-bit
> counters (so that woul mean that use of the MIB with SNMP would
> be limited to SNMPv2c or SNMPv3), then that is acceptable. I would
> say that (in IETF terms) the WG would have to agree that there is
> no objection to that approach.
> 
> > for example, if you have an application that has very significant
> > security requirements, would it be wrong to define a mib for which
> > SNMPv3 is an explicit requirement for implementations?
> >
> If you look at our security guidelines for MIBs at www.ops.ietf.org
> then you will see that we basically already have that requirement.
> It is always the user/deployment choice to use proper security.
> The MIB writers need to point out what the secuirty issues are
> what the risks are and recommend protocols that protect against
> the risks. So you see that we recommend SNMPv3 with USM and VACM
> for security sensistive MIB access (be it read or write).
> 
> > or, if you have a requirement that a notification be reliable,
> > is it wrong to explicitly state in the description that Informs
> > must be used for that notification?
> >
> I think this is somewhat different.
> In the MIB you specify the notifications.
> How they get send (TRAP or INFORM) is up to the operational
> personell, when they configure the MIBs in RFC2573.
> 
> I have no objection to adding some text to a description clause
> that would encourage USERS (i.e. not implementers, cause they
> have no control) to use INFORMs so that the notifications can
> be checked to arrive.
> 
> > is there any section of snmp std rfcs that can be used to support
> > the idea that such practices are either illegal (from a snmp std
> > point of view) or strongly discouraged (from a normal mib design
> > conventions point of view)?
> >
> There are no general rules that I can point you to that would
> address your "generic" questions.
> There is nothing in any RFC (I think... ) that says that you cannot
> just do Counter64s (which would make SNMPv1 unable to access them).
> 
> W.r.t. the INFORM, there is no way that I can see that allows you
> define a notification such that it can only be sent with INFORM.
> I think if you look at the design of SNMP and the MIBs that allow
> you configure an SNMP engine, then it clearly shows that we
> want the USERs to decide how they want notifications
> to be filtered and send and that we do not want MIB writers to
> prescribe how notifications must be sent.
> 
> Same with security. We want the protocols to provide secure mechanisms
> (and so we MANDATE that at least one security mechanism be implemented
> on all systems, but we want users to be able to slect if they use it
> or not). So if you have objects in a MIB that are sensitive, then we
> want you to describe the issues and we want you to recommend to use
> a secure mechanism.
> 
> > if it's not illegal to do such things, is it regarded as
> > highly improper?
> > if so, why?
> >
> > if there is no legal exclusion for such practices in the rfcs, how
> > does one oppose such issues when they are manifested in a MIB module
> > under design?
> >
> > is there anything that AGENT-CAPABILITIES can do to help out in
> > these situations?  such that the mib may be defined generally
> > (without such impositions of protocol) but implementations of
> > that mib may be so constrained by virtual of how the agent-capabilites
> > are defined.
> >
> implementations can always specify in an AGENT-CAPABILITIES taht they
> do not support specific objects or that they do not support write
> access for certain objects. But... the way that a lot of systems are
> build, it seems to me that at the object level, you do not know
> if access was made by a specific SNMP version or under a specific
> security level. That control is at the (master) agent.
> 
> > thanks for the insight!
> > kevin
> 
> Hope my comments help
> 
> Bert

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=