Subject: Re: SNMPv3, last call

From: [email-masked]
Date: Mon, 10 Nov 1997 18:01:49 -0500

Dick Ward does not exist.

To:       qqi @ world.std.com
cc:       snmpv3 @ tis.com, iesg @ ietf.org (bcc: Dick Ward/HNS)
From:     aeb1 @ amneris.noceast.dws.disney.com
Date:     11/10/97 10:07:26 AM
Subject:  Re: SNMPv3, last call
SMTP Headers: Headers

Aleksey:
Thanks for your gracious and prompt response.  Comments inline.
On Sat, 8 Nov 1997, Quality Quorum wrote:
> Date: Sat, 8 Nov 1997 08:12:03 -0500 (EST)
> From: Quality Quorum <[email-masked]>
> To: "Alan E. Beard" <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: SNMPv3, last call
>
> > Interest exists beyond the area director.  However, at least some
> > remaining observers of the activities of the working group have elected
> > to reserve their comments for fear of further inflaming the apparently
> > sore tempers of a small number of regular contributors to (perhaps
> > "participants in" would be more accurate) this discussion.
>
> ?????
>
> Did you read this group in say 1994 ?
>
Yes, and I reserved my comments then (except upon rare occasions) for
much the same reason.  Granted, present conditions are _much_ improved
from the great SNMPv2 wars, but I still put on my nomex-and-chain-mail
knickers before venturing into the mailing list.  ;-)
> Main point of disagrement is whether specs are good enough to be
> immediately released at the Proposed Standard or they should be kept at
> Experimental level, at least for a while. I would say that you had
expressed
> enough reservations for Experimental status to look appropriate.
>
This is a judgement call.  Experimental status is, at least in my
opinion, an option, but it may not be best for the communuity of network
designers and network administrators, particularly those in commercial
environments.  Senior management in commercial shops are unlikely to
permit introduction of any implementation based on an "experimental"
specification - it scares the bejabbers out of folks who might not
understand the IETF standards-track process.  Senior management are even
less likely to pay _money_ for implementations based on experimental
specifications.
It may be better for the commercial network-administration community to
allow these drafts to be promoted to full standards; if, in the course of
commercial implementation and deployment, improvements in the protocol
specification come into being (either as developer-coded alternatives or
private extensions to the specifications) the standards specifications
may be modified or extended as appropriate.  This is not unprecedented,
nor is it invarably fatal: SMTP and DNS have both been extended and
modified over time, and neither seems in danger of immediate demise.
> > I am willing to bet a substantial portion of my career on this
> > specification, mostly because I am firmly of the opinion that further
> > time spent on modifications will cost more that the benefit such
> > modifications are likely to bring.  I don't know how to state my
opinion
> > more clearly than that.
>
> Oh, as long as SNMPv1 NMS will be able to talk to SNMPv3 device, you have
> nothing to fear.
>
In the immediate, you are, of course, absolutely correct.  However, we
are beginning to try the upper bound of SNMPv1 function and the limits
of many SNMPv1 commercial implementations.  It would be exceedingly
helpful for us to have available from commercial sources (and at
reasonable cost) the additional function of SNMPv3 as currently defined.
> > Most user network administrators are looking for secure sets, but not
> > _exclusively_ for that function.  The overall SNMPV3 spec as proposed
is
> > probably the soundest standards-based specification,  taken as a whole,
> > that can be got in a reasonable time.  Further delay is not warranted,
at
> > least in the opinion of this user.
>
> Again, it seems like experimental level for the spec will be a fine match
to
> your opinion.
Granted, the reasoning set forth above does not _exclude_ the possibility
of experimental status.  However, I continue to be of the opinion that
promotion to full standard is a better course.  Experimental status is
not a _wrong_ choice; it is, however, not the optimum choice, IMO.
> > You have now seen at least one such expression of interest and, perhaps
> > curiously to your eyes, strong support.
>                           ^^^^^^
> In my eys your support looks like a very cautious one :).
>
Hmmm.  I had not seen it in quite that light. My support for the current
drafts is, granted, not unqualified; however, I think it can nonetheless be
accurately described as strong.  I still think that the risks of going
forward are, for the commercial network administrators, less than the
risks occasioned by further delay.  The specifications as now proposed
are, IMO, sufficiently sound to support viable (even good) commercial
implementations.  I think the drafts should be promoted to standards
status.
> > AEB
> Aleksey
Again, thank you for the time taken to discuss these matters, and for
your thoughtful and gracious response.
Regards,
AEB
Please note that the opinions above should not be construed as giving any
indication of any policy or opinion of Disney Worldwide Services or any
other Disney company.  These opinions are strictly my own.
-------------------------------------------------------------------------
Alan E. Beard
Network Design, Disney Worldwide Services
DISC Building NSA
Walt Disney World
PO Box 10,000
Lake Buena Vista, FL 32830-1000
PH: (407) 824-2004 (tie line 8273)
EMAIL: [email-masked]
SnailMail: deprecated, but see above if you must
-------------------------------------------------------------------------

---

From: "Ben Preece" <[email-masked]>
Date: Tue, 11 Nov 1997 10:05:06 +0600

I'm just another one of those people who've watched without
participating, and I don't know if opinions are still welcome.

(I think) "Alan E. Beard" <[email-masked]>

> modified over time, and neither seems in danger of immediate demise.

I have no technical objections to the contents of the documents.
However, the documents shouldn't be progressed unless there are actual
independent interoperable implementations of the spec.  Modifying a
working protocol is one thing;  fixing an unworkable protocol is
another.

If this has been published, then where can someone find a description
of the SNMPv3 interoperability tests that have been done so far?

If not, then some specific time period should be allowed to publicly
demonstrate the current implementations before progressing the
documents.

Just MHO.

-Ben
----------
Ben Preece
Ancor Communications. Minnetonka, MN
mailto:[email-masked]
http://www.ancor.com

---

From: [email-masked] (Quality Quorum)
Date: Wed, 12 Nov 1997 12:35:12 -0500 (EST)

> 
> Going over and over and over the same ground is not useful.
> 
> You have gained no support.  You yourself have said repeatedly the working
> group does not consider the problem worth solving.  Accept that.

I am accepting that, it does not mean that I agree and it does mean that 
whenever asked (e.g. in Last Call) I will provide my opinion on the
subject. 

> Give it a rest.  You lost.  Stop wasting electricity by complaining about it.

I am not complaining about anything. I posted a single post as a
part of last call process and lots of people posted follow ups and I 
do respond when I feel necessary to clarify an issue, which was 
exactly the case with  both Brian's and your post. E.g. Brian thinks
that there is no problem here at all.

> 	Bob

Aleksey

---

From: [email-masked] (Quality Quorum)
Date: Wed, 12 Nov 1997 15:23:20 -0500 (EST)

> > What is more detailed solution intellegent person needs than
> > one I had proposed many times:
> 
> Please be patient with those of us who have not been blessed with such
> intelligence.

It seems like I am trying my best, just compare Brian mails and my 
responses. 

> > 1. Reports which cannot be made secure by their nature (e.g. 
> >    "wrongDigest") should be excluded from the spec. 
> ...
> 
> The attack you hinted at presumed behaviour on the part of the command
> generator that, as far as I can tell, is not required by the current
> documents.

Problem is that current specs do limit ability of command generator to fend
off denial of service attack.

>  Receipt of a "wrongDigest" provides prompt notification that
> either there really is a wrongDigest, there is an implementation error,
> or an attempted attack.  This appears to be more information than silence.

And may I ask how this information is intended to be used by receiving
entity ?

> > It was demonstrated and I did not see anybody disagreed
> > that attack described by me will succeed. Disagreement 
> > is whether or not it is worth bother with protecting
> > against it.
> ...
> 
> What about Uri's message (which Aleksey quoted)?  It seemed to be a
> pretty thorough analysis of just how far (or not) such an attack could go.

Yes it is prety good analysis, I am wondering do you agree with its
conclusion ? As far as I understand it concludes that SNMPv3 entity
is indeed open to very simple attack.

>  Randy Presuhn            BMC Software, Inc. (Silicon Valley Division)

Alkesey