Question about one place in W. Stallings' book SNMP, SNMPv2, SNMPv3, RMON 1 and 2 - SNMP

Hello newsgroup participants,

On page 334 of his book Mr. W. Stallings writes following:
"... In a nutshell what happened is this. There was little enthusiasm
among vendors and users for the way in which security was specified in 1993
documents. When the work began on the 1996 documents, it was hoped that some
minor tune-ups to the security portion would suffice. Overall, the working group
was operating on a rather tight time schedule to produce a revised version
of SNMPv2 so that vendors could move forward with products. As the effort
was nearing completion, one of the participants demonstrated to the satisfaction
of the working group as a whole that the security portion of SNMPv2 was fatally
flawed..."

Sorry for extended quotation but it was needed.
Basically what I am interested is in expnaded presentation
of the stroy and not the story in the nutshell. Here are my
questions:

1) Does Mr. Stallings mean SNMPv2p when he speaks about 1993 documents?
2) Why vendors and users were not happy with the security implementation
in SNMPv2p, for what reasons?
3) Is the demonstration of fundamental flaw documented somewhere? What
is actually wrong with security model?


Kind Regards
Ariel Burbaickij

Ariel Burbaickij wrote:

> Here are my questions:

> 1) Does Mr. Stallings mean SNMPv2p when he speaks about 1993 documents?

Yes.

> 2) Why vendors and users were not happy with the security implementation
> in SNMPv2p, for what reasons?

I think even the authors of the specs had some difficulties to get
SNMPv2p configured. I don't think that the security processing itself
was the problem. (Note however that SNMPv3 has some additional nice
features that simply were invented later, such as localized keys.)

> 3) Is the demonstration of fundamental flaw documented somewhere? What
> is actually wrong with security model?

You have to read the mailing list archives for the real story. But I
remember that I tried to configure SNMPv2p in our lab at that time and
I failed miserably myself. There were attempts to fix this problem by
defining algorithms to automate the SNMPv3 administration (see RFC
1503), but that did not help much. If an operator can't understand
the configuration of a network service without tools, he will most
likely not turn the service on.

Note that even in 2004, we still hear operators complaining about the fact
that SNMPv3 still comes with its own key management system and does not tie
into their existing authentication and authorization infrastructures.
So to some extend, we still face the same problem of making things
actually not only secure, but deployable secure. One of the old SNMP
requirements that was carried forward all the years is that SNMP
should not rely on any other network services (except IP and UDP).
If you look at the success of deployment of secure versions of SNMP,
one can ask the question whether the strict interpretation of this
core requirement has been a good idea.

This is of course my totally biased opinion and I am sure others will
disagree with my judgement of SNMP's history.

/js

--
Juergen Schoenwaelder International University Bremen
P.O. Box 750 561, 28725 Bremen, Germany

Juergen Schoenwaelder wrote in message news:<1089997346.599218@salvator.ibr.cs.tu-bs.de>...
> Ariel Burbaickij wrote:
>

>
> > 3) Is the demonstration of fundamental flaw documented somewhere? What
> > is actually wrong with security model?
>
> You have to read the mailing list archives for the real story.
Sure, but what mailing list is meant?
> Note that even in 2004, we still hear operators complaining about the fact
> that SNMPv3 still comes with its own key management system and does not tie
> into their existing authentication and authorization infrastructures.
> So to some extend, we still face the same problem of making things
> actually not only secure, but deployable secure. One of the old SNMP
> requirements that was carried forward all the years is that SNMP
> should not rely on any other network services (except IP and UDP).
> If you look at the success of deployment of secure versions of SNMP,
> one can ask the question whether the strict interpretation of this
> core requirement has been a good idea.
As about IP and UDP being only assumptions. You know if it burns
you can not expect any sophisticated tools being available, so
there is IMHO some justification in minimalistic approach to requirements
for SNMP.

Thank you.


Kind Regards
Ariel Burbaickij

Ariel.Burbaickij@web.de wrote:

> As about IP and UDP being only assumptions. You know if it burns
> you can not expect any sophisticated tools being available, so
> there is IMHO some justification in minimalistic approach to requirements
> for SNMP.

Tell me: If your network burns such that for example TCP stops to work,
do you use SNMP to repair it? Or do you use ping/traceroute & friends
to diagnose the problem and if necessary the phone to instruct someone
to type something into a CLI?

Note, I am not asking for theory - I am asking for your practical
experience here.

/js

--
Juergen Schoenwaelder International University Bremen
P.O. Box 750 561, 28725 Bremen, Germany

Juergen Schoenwaelder wrote in message news:<1090191406.575333@salvator.ibr.cs.tu-bs.de>...
> Ariel.Burbaickij@web.de wrote:
>
> > As about IP and UDP being only assumptions. You know if it burns
> > you can not expect any sophisticated tools being available, so
> > there is IMHO some justification in minimalistic approach to requirements
> > for SNMP.
>
> Tell me: If your network burns such that for example TCP stops to work,
> do you use SNMP to repair it? Or do you use ping/traceroute & friends
> to diagnose the problem and if necessary the phone to instruct someone
> to type something into a CLI?
>
> Note, I am not asking for theory - I am asking for your practical
> experience here.
>
> /js

Well, steps are:
1) Look up the status of piece of Hardware via snmp (believe it or not ;-))
2) status ok but still some complaints running in - go one level below
and use ping, traceroute, reboot whatever.

I guess thorugh formatting my original question was not noticeable very
well -the question was what is the name of the mailing list where flaws
of SNMPv2p were discussed?

Kind Regards
Ariel Burbaickij

Ariel.Burbaickij@web.de wrote:

> I guess thorugh formatting my original question was not noticeable very
> well -the question was what is the name of the mailing list where flaws
> of SNMPv2p were discussed?

Actually, the archives are pretty hard to find. You can find the
mailing lists by looking and old IETF meeting proceedings which
include snapshots of the WG charters. There are also points to
archives, which however often seem to just disappear from the
Internet.

/js

--
Juergen Schoenwaelder International University Bremen
P.O. Box 750 561, 28725 Bremen, Germany

Juergen Schoenwaelder wrote:
>
> Ariel.Burbaickij@web.de wrote:
>
> > I guess thorugh formatting my original question was not noticeable very
> > well -the question was what is the name of the mailing list where flaws
> > of SNMPv2p were discussed?
>
> Actually, the archives are pretty hard to find. You can find the
> mailing lists by looking and old IETF meeting proceedings which
> include snapshots of the WG charters. There are also points to
> archives, which however often seem to just disappear from the
> Internet.

If you don't mind downloading a 41 Mbyte text file, the SNMPv2
mailing list archive from mid-May 1993 to January 2000 is still
available on-line at this URL:

ftp://ftp.research.telcordia.com/pub.../snmp2/archive

For the super-dedicated aficionado of the history of SNMP, there
is also an earlier archive in the same (snmp2) directory.

nobody

dperkins@snmpinfo.com wrote in message news:...
> HI,
>
> The response by Juergen below is pretty much on target.
>
> Ariel, I'm curious why you want to find out about this? Also,
> why are you using Stallings as a source? He was not there.
> He has only second or third hand info.
>

Interest is in this case both job-related and also personal one.
I would find it interesting to understand whether SNMPv2p is just
unwieldy, complex or just downright conceptually wrong. Does this
answer satisfy your curiosity? To be honest I do not think that
it it very fruitful approach to judge about books based only on
the "who was where when" principle, Stallings had his publisher
and proably also his readership, so they should decide. I have borrowed
the book from the library ;-). Do you think that your book or
article with the same title "Understanding MIBs" does a better
job of explaining this aspect or for this matter "The Simple Book"
by Rose, he was definitely there

With Best Regards
Ariel Burbaickij