RE: MIB

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Comments/answers inline

Bert

> ----------
> From: 	RJ Atkinson[SMTP:rja@inet.org]
> Sent: 	Monday, June 05, 2000 4:10 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	Juergen Schoenwaelder; Spencer.Giacalone@predictive.com;
> djoyal@nortelnetworks.com; mibs@ops.ietf.org
> Subject: 	RE: MIB
> 
> At 09:34 05/06/00 , Wijnen, Bert (Bert) wrote:
> >They SHOULD care about them equally well, and they should read them.
> >The security section should list security aspects both for users and for
> >implementers (at least so I think).
> 
> I wish they all did so.  Today, they don't.  Sigh.
> 
> >See I come from an agent/subagent environment. Those people who implement
> >a MIB, they do not always know on which plaforms together with which
> version
> >of an SNMP agent they get installed/deployed. And in fact, one of the
> strong
> >motivators for sub-agent technology (agentX on the stds track, but
> various
> >other technologies as well) is the fact that a MIB implementer does not
> >need to worry about the security mechanisms of the SNMP protocol itself.
> 
> That is a useful clarification.  Thanks.
> 
Happy to see this was part of our dis-connect, that we have now cleared.

> IMHO, it sounds like the interface between the sub-agent and the master
> agent needs to be enhanced so the sub-agent has knowledge of whether
> it is running on SNMPv1 or SNMPv3.  Such knowledge has impact on other
> things (e.g. 64-bit counters) unrelated to security.
> 
Well, for such things as counter 64 and such (i.e. conversion between SMIv1
and SMIv2 and between pdu-version specific stuff, we have written
up how to convert, see RFC2576. I believe that agentX spec also 
refers to that document.
We tried very hard in agentX spec to make the specific SNMP message
version (and which security is used) irrellevant for the person who
implements the MIB in a subagent. That way, if a new message format
for SNMP comes along, then the instrumentation does not need to be
changed, anbd that is where most "users" of SNMP have invested 
most of their money/resources.

> >All of that supposedly is done by the master agent.
> >So writing in a particular DESCRIPTION clause of a particular object that
> >an aboject should not be writable under conditions that are outside the
> >control of the MIB implementer is sort of strange to me.
> 
> See above.
I guess I should add that in a monolithic agent... and possibly in some
sub-agent technology a MIB implementer might actually see it. But I can
not say that I like that idea, and certainly I don't want to mandate that
a piece of MIB siunstrumentation SHOULD know about the particular
SNMP msg format or PDU version.

> >I hope that the above explains why I did not immediately see how an
> >implementer even knows if SNMPv3 is implemented in the environment 
> >where the MIB gets deployed.
> 
> My perception is that most OSPF implementations aren't currently
> using anything as sophisticated as master-agent/sub-agent.  Most
> OSPF vendors that I'm familiar with have a single monolithic agent
> (yes, @Home regularly insists on knowing about the deep internals of
> its vendors' products prior to purchasing them).
> 
That's fine. and so for you the description clause might be usefull,
cause you could possibly follow that guideline.
But even in this situation, I would rather see you make the access
(read or read-write) part of access control.

> Perhaps the master/sub-agent concept is more widely deployed elsewhere
> or perhaps it is still gathering steam or perhaps I'm confused ?
> 
I guess that it depends a lot on the type of system you develop and on
how much SNMP interaction you expect to take place.

> > > specifying an optional-to-implement security mechanism is sufficient,
> > > when operational experience shows that options in IETF specs generally
> > > do not get implemented. (VRRP is a fine example of this, prior to
> > > the last IETF/DC meeting).
> > > 
> >correct, but then (as I am sure you know), the last one did not pass
> without
> >proper authentication added (at least that is what I recall off the top
> of
> >my head).
> 
>          Primarily because Jeff Schiller and I made a huge deal of this
> issue 
> in a particular private meeting.  However, vendors still haven't made
> motion
> to implement security, so the main effect is that VRRP is stalled on the
> standards-track for now.
> 
>          If a MIB implementer doesn't have control over read-write vs.
> read-only, then how could the MIB implementer actually implement any
> recommendations made either in DESCRIPTION text or in Security
> Considerations 
> or in other parts of the MIB document ?
> 
The MIB implementer in my view cannot... 
(but in your monolithic implementation, you might decide to use
that info and implement acocrdingly. Certainly of the MIN-ACCESS
states that read-only is OK in such a situation, then you could force
read-only at the instrumentation lvl).
But he/she should read the sec.section, because there could
be other security related stuff that he needs to know about.

>          I'm mightily confused here on why we would even have educational
> text
> for implementers in Security Considerations -- if the MIB implementers are
> 
> incapable of actually implementing any of the guidance.
> 
Hope some of my answer explain

	Bert