Re: snmpv2 Will it flood us or be slow

[Frank Kastenholz <[e-mail]>]

 >  >    > My view of V2 is that it is more like the Social Security
 >  >    > Administration -- an administrative nightmare that has far more
 >  >    > administrative framework that is reasonable to do a simple job.
 >  >
 >  >   It seems to me that IF you want
 >  >   all the things in V2 THEN you must "pay the price" however, if you do
 >  >   not want some stuff then you do not need to configure that stuff.
 > 
 > If you draw a graph of agent complexity versus agent capabilitie, you
 > won't see a nice straight line.  Rather you will see a major step
 > function.  If you want authenticated transactions (the lack of which
 > is the purported reason why few SET requests have ever been issued in
 > real-life) then there is an extremely large increment in the
 > complexity which must be active in an agent.
 > 
 > After all the years of people saying that the reason they don't do SET
 > requests is because of lack of authentication, is it realistic to
 > believe that agents are going to now avoid bearing the cost of
 > authentication?  Of course not, any device which accepts Set requests
 > is going to authenticate them.  And we all admit that it will be a
 > significant incremental cost to use this one, all important feature.

Well, I'd suggest that at the time, when we didn't know the true costs
of doing authentication it was not unreasonable to make the claim "no
sets without authentication". Now that we know the cost, some people
might rethink this: "Gee customer, you can have authentication for sets,
but it will increase the cost of the box by $X (more RAM, ROM, nvram)
and it will increase your `cost of use' (keeping track of keys, etc)".


Of course, just because you have the ability to authenticate packets in
the protocol does not mean that the end-users will actually use that
ability. If a user feels that their network is reasonably secure then
unauthenticated sets might be used.

Finally, just as we keep saying that MIBs are not the "carbon-based-user
interface specification" with regard to MIBs used to do management, the
MIB (and the SNMP protocols/algorithms) are not the interface that a
carbon-based-user should be dealing with. I imagine that some bright,
greedy, start-up company will come up with a simple-to-use manager
that lets a human set up all this stuff.

 >  >   Furthermore, if your agent-system does not need something then do not
 >  >   implement it and constrain the configuration interfaces (MIBs, consoles,
 >  >   etc) accordingly -- if you feel that you do not need privacy in your
 >  >   agent then A) do not implement DES and B) don't allow someone to
 >  >   set the partyPrivProtocol to anything other than noPriv".
 > 
 > The privacy protocol is actually the easier part of things.  It's the
Privacy was simply an example -- the first that came to mind.

 > authentication, the views, the access lists that is the real pain.
 > All those internal mib-cross references that must be maintained.
 > 
 > All those MIB data structures will exist, need to be initialized, need
 > to be maintained, need to be handled in case they become inconsistent.

Only if you truly wish to support the full richness. In the
SNMPv1+Security implementation that I did we decided that only
two views would be needed -- one containing the party secrets and the
other not containing the party secrets. Thus, the entire view-mib and
its underlying capabilities was collapsed to a single bit and maybe
100 lines of code.

 > (BTW -- the fact that the choice of protocol, i.e. noPriv,
 > paryPrivProtocl, etc., is expressed as a variable-lengh, multiple byte
 > OID rather than a simple enumerated byte is an example of the silly
 > extent the protocol has gone to accomodate any and all unforeseeable
 > changes.)

Look at the discussion on the interface mib mailing list wrt ifType.

 > As Simon Hacket put it: All we wanted out of V2 was a way to safely do
 > Sets.  Instead of the racehorse we wanted, we got a camel -- a
 > horse designed by a committee -- which is big, slow, smells bad, and
 > spits, although it will do well on extremely sandy racetracks.

That's all that you and Simon wanted. Others wanted different things --
such as more efficient bulk-retrieval, or instance-level views.
Everyone has valid reasons for requesting their favorite feature.
Who is to say that the bulk-retrieval people's needs are less important
than yours?

Given that this is the IETF, there is going to be a large amount of
camel building. About the only grounds that are available for ignoring
something are "That's technically broken" or "That does not do anything
useful".

Fortunately, within the SNMP area, the protocol and MIBs and SMI are all
rich enough in the right areas to make it relatively easy to not do some
things and to not do them in a protocol-conformant manner.

I was perfectly happy with SNMPv1+Security -- and you see how much _I_
was listened to :-)

--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
[phone]