Re: COPS vs. SNMP

[David Partain <David.Partain@ericsson.com>]

[ not posted from a subscriber address ]

Hi all,

bw = Bert
dd = David Durham

bw> David, I am not sure what you are trying to tell people?

dd> That before we start calling SNMPConf Done, we should take a step
dd> back and carefully consider the security issues associated with allowing
dd> local scripts to control the configuration of a device. Seems there is 
more
dd> work to do here.

Ah hah.  So it's the model of local control and local decision
making which makes you uncomfortable?  That someone would write
an application that they download to a machine and it runs on
that machine locally without relying on a higher-level entity to
take the decision?  I'm just trying to see where the gripe is.

I don't see that that has _anything_ whatsoever to do with SNMP
(which was the focus of your mail about the CERT advisory),
but it certainly is related to SNMPCONF (of course).  Of course,
this model has existed in DISMAN for a number of years, as well
as in various other areas of technology.

bw> The SNMP CERT advisories have NOT talked about a flaw
bw> in the SNMP Protocol at all. They have talked about implementation
bw> bugs. Further, it seems that most implementation bugs have been
bw> in the area of not properly decoding BER encoded SNMP packets.

dd> Perhaps,

It's not a question of "perhaps".  It's absolutely certain.
Please read the advisory.

dd> but that raises serious questions about using the current
dd> installed base of SNMP for configuration.

Of _course_ the current installed base is not appropriate for
configuration, if it's based on SNMPv1.  No one's claiming
anything else.

dd> It is not clear to me where a
dd> problem with implementations is to blame vs. the protocol definitions.

Maybe reading the CERT advisory will help.

dd> There are a lot of SHOULDs and MAYs in the specs that help contribute to
dd> implementations going awry.

In this case, it's classic programming errors in handling
buffers.  It's exactly the same kind of programming errors that
have affected a very wide range of available software from
OS kernels to web servers to printing systems, to....

Don't try to blame this on the protocol.  It won't fly.

bw> Since the COPS-PR with PIB approach also uses BER encoding for
bw> sending the configuration/policy information, I would suspect
bw> that COPS-PR implementations have the same potential risks!!!

dd> COPS and COPS-PR security mechanisms are NOT BER-based.

It has absolutely nothing to do with security mechanisms.
It's buffer overflows.

dd> The security
dd> mechanisms use fixed size COPS objects and tried & true TCP security
dd> mechanisms. Once the persistent & secure client/server communication is
dd> established, only then does BER come into play. Even then, the BER objects
dd> are still wrapped in COPS objects, providing an extra level of validation
dd> to avoid buffer overruns and the like.

If the folks writing COPS/COPS-PR code write perfect code,
I'm sure there'll never be any COPS-related problems with any
kind of denial of service or buffer overflow attack.

Cheers,

dlp