RE: MIB

[RJ Atkinson <rja@inet.org>]

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.

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.

>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 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).

Perhaps the master/sub-agent concept is more widely deployed elsewhere
or perhaps it is still gathering steam or perhaps I'm confused ?

> > 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 ?

         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.

Ran
rja@Inet.org