Ongoing V2 discussions....Re: Configuring Community Names

["Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <[e-mail]>]

 > So, our exchange has been worthwhile, and for that I thank you.

Thanks for the tone and substance of your note.

I know that some will object to this material going to both the V1 an
V2 lists, but I think it is worthwhile for this kind of discussion to
be heard by the SNMP community at large.  The sooner we get to V2 the
better.  V2 is well designed, concise, and useful.  And for anybody
who is listening in -- I consider the issues which Keith and I are
discussing as in no way questioning the need to quickly move to V2.

 > You
 > have pointed out that the conformance macros for the Party MIB are
 > broken.  Would you like to suggest what they should be, or shall I do
 > that ?

As for working with the macros.  I'm not very good with those.  (BTW,
one of the areas in which V2 really shines over V1 is the expansion
of the formalized mechanisms by which MIBs and such are expressed.)

A couple of points however.

The original message on this thread was a about configuring community
strings, a V1 concept.  Hence my principle text was how one might do
some V2 things in V1.  In all of that, one message was clear as it
flowed from my mind to my fingers, at which point it may have been
garbled: you can do authentication in V1 using mib variables, but it
is clumsy and hard and requires extra packet exchanges.  In other
words, in terms of authentication V2 wins hands down, no contest.

Regarding the moving of secrets by x-oring the new, proposed value
with the old.  It is a good mechanism.  It is quite generalizable to
other MIB variables (as long as the manager can really and truely
know what the old value is in the agent, even in the presence of
other active managers.)  Whether this mechanism constitutes
cryptography for purposes of export control is going be decided by
folks other than ourselves.  My own personal approach would be to be
ultra-conservative and apply for an export license.  What scares me,
however, is that that act may sensitize the government and mess
things up for everybody else who didn't apply.  It's a catch-22.

One of the issues which your note clearly illustrates is that to get
authentication you need some place to hold authentication data about
your (the snmp engine's) potential peers, hence the party
relationship.  They you need a way to deal with an increase/decrease
in the manager population, hence dynamic creation of parties.  And
since different managers may have different needs to know we get into
access lists and views.

It reminds me of the time I needed to clean a closet.  But to clean
the closet I needed a place to put the stuff in the meantime.  The
garage was such a place, but to make the stuff fit, I needed to
reorganize the garage.  Reorganizing the garage required that I take
everything out and put it back neatly.  And since everything was out
of the garage, it should be painted....  All this just to clean a
closet. 

The same situation may exist in V2, and that is the fundamental
question I am trying to reach.  Which of these mechanisms are really,
absolutely necessary to achieve the degree of security and
flexibility which we actually need in practical use, and which are
"mere" features?

For example, lets look at the class of access control policies that
can be manifested by views and access control lists.

Basically those mechanisms can enforce only subset the MIBs
information base into sections.  Different managers may have
different rights to view or modify variables.

That kind of policy is useful, but does not support policies that say
that manager X is able only to view summary data, or see data only if
the value of that data meets certain conditions.  These kinds of
restrictions are not so fanciful; they are quite common in real life
paper systems.

I don't see why the access control mechanism in V2 is any more
necessary than the latter form I mentioned.  I would submit that both
forms are "features" rather than fundamental necessities of network
management.

Moreover, why is the ability to dynamically create and alter all of
these mechanisms necessary rather than a feature?  Is their cost
worth the effort.  That's a judgement call and requires a crystal
ball to resolve.

The effort entailed just by the existence of these mechamisms isn't trivial:
  -  On the agent end, one has to build agents that have at least
     enough smarts that they can correctly detect and reject requests
     for those functions they don't implement.
  -  Manager stations need to be able to deal with all the various
     error modes that agents can return.  (Yes, code should always
     do this, but there are errors which occur frequently, due to
     mismatched abilities between manager/agent, and those that
     should be rare, like a true protocol failure.  I claim that the
     former take a great deal more code to handle because one is
     trying to keep the human out of the loop.  The latter form can
     often be projected back to the human with a simple "can't do it"
     message.)
  -  The number of mis-implementations will increase.  This will, in
     turn, increase the size and complexity of the error handlers in
     the manager.  (Even in V1 I find that snmp error handling code in
     managers is often larger than the real snmp payload code.)

 > Ok, so now, apart from wanting to see some implementation experience of
 > clocks (which is fine by me), you take back all your previous comments
 > about the "complexity of V2" except for two points: 

Well, let's not put words into my mouth.  I'm quite capable of
inserting my own foot quite far down my own throat without any
help. :-)

I still think that V2 is too complicated.  But as your note well
indicates, the design does have many interlinkages, making it very
hard to say what is fundamental and what is not.  I'm not asking an
easily answered question, and I don't expect any clear answers.  In
fact, I will be perfectly happy if as a result there is absolutely no
change in the specification at all.  I only want to be sure that we
are able to articulate a specific need for all the parts.

Regarding clocks and other implementation experience:

Yes, I really am concerned that there are not some hidden glitches in
clocks.

Which leads me to an offer I'd like to make.  (I hide it deep down in
the depths of a message so that only the serious minded will see
it...)  At the August Interop show in San Francisco, I'd like to get
V2 managers into the NOC and V2 agents onto the floor.  If you (or
anyone out there listening) have any V2 gear that you think might be
useful, let me know.  We will be able to prestage all the stuff in
Sunnyvale.  This is not a press/hype event.

BTW, I can confirm the operational need for different views.  But my
own experience has been that pretty gross, static carving of the MIB
is adequate.

			--karl--