RE: MIB

[RJ Atkinson <rja@inet.org>]

At 08:44 05/06/00 , Wijnen, Bert (Bert) wrote:

> > The discussion in Security Considerations is universally ignored by
> > implementers.  Sad, but true.  WHile I agree documentation is necessary,
> > I don't think its close to being sufficient for situations like the
> > particular one in the OSPF MIB.
> > 
>Mmm... so why the heck are we in the IETF making so much trouble when
>authors/editors do not specify such a security section correctly???

         So that operators can get a clue about what residual security risks
exist in the protocols and standards that they deploy.

         The issue is that most **implementers** do not care about security.
Please read what I wrote originally.  It was stated precisely.

>In any event, the SNMP/MIB/VACM approach is such that we provide the
>tools for people to use proper access control to sensitive objects. We do 
>not want to prescribe as the IETF how people treat risks. Some people
>may decide that their network is secure in some other way...... 
>   - In any event, we give them the tools.
>   - we make good recommendations
>   - they (user/customer) must take the responsibility to properly deploy.

         However, when I tried to suggest that a specific object be READ-ONLY
unless those theoretical tools have actually been implemented (hence 
are actually available to operators, versus not being available,
as is the current and near-term deployed reality), then the SNMP community 
shoots this down.  This works towards SNMP remaining a monitoring
tool, rather than a management tool.

         If you re-read the original proposed text, it did NOT require that
the operator do anything, though it made suggestions.  The original
proposed text DID require that implementers have a certain object
as READ-ONLY unless they had *implemented* at least SNMPv3 in the agent.

         Please stick to what I write and don't imply I said something else.

>For all I know, we (IETF/IESG) do require that protocols provide the
>proper security tools/mechanisms. 

         Not consistently, IMHO, though its better now than it
was several years ago.  In particular, many on the IESG feel that
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).

>I do not believe that we require that
>a user/customer MUST use them... even though we strongly recommend so.

         I've NEVER suggested this.  Please lets stick to what folks
actually say in this conversation and not raise red herrings.

         I've suggested that certain mechanisms be MUST IMPLEMENT
in order for a particular OID to be writable.  There is significant
amounts of past precedent within IESG and IETF to make security
mechanisms mandatory to implement in sundry situations (e.g. IPv6).

Thanks,

Ran
rja@Inet.org