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(_at_)cs(_dot_)columbia(_dot_)edu]
Sent: Monday, June 05, 2006 8:21 PM
To: David Harrington
Cc: randy_presuhn(_at_)mindspring(_dot_)com; ietf(_at_)ietf(_dot_)org
Subject: Re: Best practice for data encoding?
On Mon, 5 Jun 2006 20:07:24 -0400, "David Harrington"
<ietfdbh(_at_)comcast(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf