RE: MIB

[RJ Atkinson <rja@inet.org>]

At 05:55 05/06/00 , Wijnen, Bert (Bert) wrote:
>However... it seems to me that the reason you list below is
>not a proper reason to make something a MIN-ACCESS of read-only.
>In my view, you would use the VACM table (can also be used with
>SNMPv1, see RFC2576) to exlcude access without proper 
>authentication and/or privqacy.

In practice, which deployed SNMPv1 implementations support VACM today ?

         My experience is that --zero-- support VACM today and that
--zero-- are likely to support VACM anytime in the near future.  

         However, I think VACM is actually *irrelevant* here.  The reason to 
make the object READ-ONLY unless SNMPv3 is implemented in the agent
is because that OSPF MIB object permits one to downgrade OSPF authentication 
from cryptographic strength to cleartext-password (i.e. zero) strength.  
If  we at least ensure that the object can only be twiddled when a SNMP 
implementation has cryptographic protections (i.e. MD5 Auth) available 
to the operator [1], we significantly reduce the risk to the operational 
OSPF system. [2]

Ran
rja@Inet.org

[1] One cannot legislate that an operator actually enable MD5 Auth as
         that is an operational policy matter.  It is reasonable (IMHO)
         to legislate that an implementation treats the object as RO
         unless it at least has reasonable protections available to the
         operator so the operator has a chance to do the right thing.
[2] This is probably the point where Randy Bush would point out that no
         operator that he knows actually enables any SNMP SETs anyway...