Subject: RE: COPS vs. SNMP

From: "Durham, David" <[email-masked]>
Date: Mon, 25 Feb 2002 11:26:56 -0800

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> 
> David, I am not sure what you are trying to tell people?

[Dave] That before we start calling SNMPConf Done, we should take a step
back and carefully consider the security issues associated with allowing
local scripts to control the configuration of a device. Seems there is more
work to do here.
> 
> The SNMP CERT advisories have NOT talked about a flaw
> in the SNMP Protocol at all. They have talked about implementation
> bugs. Further, it seems that most implementation bugs have been
> in the area of not properly decoding BER encoded SNMP packets.
> 
[Dave] Perhaps, but that raises serious questions about using the current
installed base of SNMP for configuration. It is not clear to me where a
problem with implementations is to blame vs. the protocol definitions. There
are a lot of SHOULDs and MAYs in the specs that help contribute to
implementations going awry.  

> Since the COPS-PR with PIB approach also uses BER encoding for
> sending the configuration/policy information, I would suspect
> that COPS-PR implementations have the same potential risks!!!
> 
[Dave] COPS and COPS-PR security mechanisms are NOT BER-based. The security
mechanisms use fixed size COPS objects and tried & true TCP security
mechanisms. Once the persistent & secure client/server communication is
established, only then does BER come into play. Even then, the BER objects
are still wrapped in COPS objects, providing an extra level of validation to
avoid buffer overruns and the like. 

... But I think it is good to analyze COPS-PR in this regard. Certainly, we
should be assured that CERT will have no issues with COPS-PR in the future.
   
> Bert
> 
> > -----Original Message-----
> > From: Durham, David [mailto:[email-masked]]
> > Sent: Monday, February 25, 2002 7:32 PM
> > To: 'Tricha Anjali'; [email-masked]
> > Cc: Ian F. Akyildiz
> > Subject: RE: COPS vs. SNMP
> >
> >
> > I'm interested in what the industry adoption of SNMPConf is/will be.
> > Particularly given that CERT is already advising that
> > administrators TURN
> > SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of
> > CERT advisories
> > and other bad press due to its
> > troubling susceptibilities. Now just imagine allowing people
> > to actually
> > download viruses and worms via SNMPConf PM MIB's Scripts.
> > -Dave
> >
> > http://www.internetwk.com/story/INW20020213S0002
> >
> > > -----Original Message-----
> > > From: Tricha Anjali [mailto:[email-masked]]
> > > Sent: Monday, February 25, 2002 9:38 AM
> > > To: [email-masked]
> > > Cc: Ian F. Akyildiz
> > > Subject: COPS vs. SNMP
> > >
> > >
> > >
> > > Hello,
> > >
> > > We have been following the IETF activities concerning the
> > > ongoing work in
> > > the fields of SNMP and COPS. It seems that at the meeting in
> > > March 2000 in
> > > Adelaide, the snmpconf working group was formed for issues
> > > dealing with
> > > policy-based network management after the BOF about network
> > > management in
> > > Dec 1999. However, now the group seems to have accomplished
> > > its charter
> > > and finished. Does this mean that the discussion has been resolved?
> > >
> > > We would like to know if the resource reservation in a
> > > network can/should
> > > be achieved via COPS? If yes, how is it advantageous over SNMP?
> > >
> > > Any help will be appreciated!
> > >
> > > Thanks in advance,
> > >
> > > Tricha
> > >
> > > -------------------------------
> > > Tricha Anjali
> > > Broadband & Wireless Networking Lab
> > > School of Electrical and Computer Engineering
> > > Georgia Institute of Technology
> > > http://users.ece.gatech.edu/~tricha/
> > >
> > >
> > >
> > >
> >

---

From: David Partain <[email-masked]>
Date: Tue, 26 Feb 2002 13:03:13 +0100

[ 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