RE: MIB

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

Ran... seems you read more in my email than I intended.
         And this may indeed be because I am not concise/precise.
Similarly, I may have read more in your email than you meant.

In general, pls do not treat this as a personal attack (I don't think you
do,
but I just want to be clear). 

Maybe when you read my new comments you understand where
I am coming from.


More Comments inline.

Bert

> ----------
> From: 	RJ Atkinson[SMTP:rja@inet.org]
> Sent: 	Monday, June 05, 2000 3:07 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	Juergen Schoenwaelder; Spencer.Giacalone@predictive.com;
> djoyal@nortelnetworks.com; mibs@ops.ietf.org
> Subject: 	RE: MIB
> 
> 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.
> 
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).

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

>          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.
> 
I hope that the above explains why I did not immediately see how an
implementer
even knows if SNMPPPv3 is implemented in the environment where the MIB
gets deployed.

> >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
Well, if people see IETF Last Calls for documents that do not include a
proper 
security section, then they can also alert the IESG that such is the case.
I am pretty sure that the current IESG will take note and action.

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

> >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.
> 
Appology. You did not state that in such text. But given how I see a
master/subagent
environment, that is the only way it can be achieved. So that is why I sort
of
concluded that.

>          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).
> 
Hope the above explanatiuons make it clear why I think that the suggested
text
for the specific object seems not to make sense to me. Access control is
outside the scope of a MIB implementer, and in many implementations
read-write
access vs read-access is not under control of the MIB implementer.

> Thanks,
> 
Welcome,
Bert