Re: Best practice for data encoding?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Harrington wrote:

I agree that complexity breeds bug-prone implementations.

I wasn't around then; did anybody push back on SNMPv1 as being too
complex? http://www.cert.org/advisories/CA-2002-03.html is mainly
about SNMPv1 implementations. ;-)

I wasn't there to push back, but when I got asked to implement it back then
the Simple part such seemed like something between a fib and the Big Lie.
Did we really need ASN.1 to define a debug peek/poke-like protocol?

      Mike

dbh

-----Original Message-----
From: Steven M. Bellovin [mailto:smb@xxxxxxxxxxxxxxx] Sent: Monday, June 05, 2006 8:21 PM
To: David Harrington
Cc: randy_presuhn@xxxxxxxxxxxxxx; ietf@xxxxxxxx
Subject: Re: Best practice for data encoding?

On Mon, 5 Jun 2006 20:07:24 -0400, "David Harrington"
<ietfdbh@xxxxxxxxxxx> wrote:

Hi
The security problems identified in
http://www.cert.org/advisories/CA-2002-03.html "Multiple
Vulnerabilities in Many Implementations of the Simple Network
Management Protocol (SNMP)" are not caused by the protocol choice
to
use ASN.1, but by vendors incorrectly implementing the
protocol (which
was made worse by vendors using toolkits that had the problems).

If "Multiple Vulnerabilities in Implementations" were used
to condemn
the encoding methods of protocols that have been incorrectly
implemented, then we would have to condemn an awful lot of IETF
protocols as being very (security) bug prone:
Works for me....

More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember
point (3) of RFC 1925.

I'll note that a number of the protocols you cite were indeed criticized *during the design process* as too complex. The objectors were overruled.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]