Subject: COPS vs. SNMP

From: Tricha Anjali <[email-masked]>
Date: Mon, 25 Feb 2002 12:38:03 -0500 (EST)

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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 25 Feb 2002 19:49:06 +0100

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

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.

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!!!

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,
> >

---

From: "Sahita, Ravi" <[email-masked]>
Date: Mon, 25 Feb 2002 11:17:09 -0800

Tricha,

Thanks for tracking the COPS activity in the IETF.
Within the RAP wg, the COPS base protocol, and the 
extensions - COPS for RSVP and COPS-PR have been RFC'ed.
These are RFC 2748, 2749 and 3084 respectively. 
SPPI describes the PIB language spec which
is one of the data models COPS-PR can carry. This
is described in RFC 3159.

Regarding COPS-PR features, some important notions are 
described in the COPS-PR RFC 3084 in Section 1.1.

Also, David Harrington sent this info on the list a few days
back - Erik Liden and Anders Torger wrote a master's thesis 
in January 2000 on the "Implementation and Evaluation of the 
Common Open Policy Service (COPS) Protocol and its use for 
Policy Provisioning" that you might want to review.
Its at http://extwww.lulea.trab.se/cops/

Intel has an open source COPS Client SDK for the above
specifications at http://www.intel.com/labs/manage/cops/
There will be an update soon that will include a client side 
PIB Control Interface Generator.

Hope that helps.
Ravi

-----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?

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: "Harrington, David" <[email-masked]>
Date: Mon, 25 Feb 2002 15:19:43 -0500

Hi Tricha,

I recommend that if you want answers from both sides of the issue of COPS/PR
versus SNMPCONF, you should send your mail to both the RAP WG and the
SNMPCONF WG. And you should be prepared for very biased, and often
inflammatory and misleading, information from both sides.

There are a number of differences between these two approaches, and neither
is a clear winner. I don't find either approach compelling, but I need to
recuse myself, since I have been a co-chair of the SNMPCONF WG in the past,
and have done work on the COPS/PR specifications. You'll need decide for
yourself which is best. I'll give you an overview of things to look for when
doing your analysis, and I'll try to be neutral. 

I have two sections. One compares their provisioning ability; the second
deals with security issues. You'll need to decide what's important to you
and your customers.

COPS/PR:
Advantages: Designed specifically for provisioning with all the benefits of
a protocol designed for the purpose at hand. Event-driven. Object-oriented.
Includes explicit provisions for fail-over, role-combinations, and other
provisioning-related issues. Able to provision SNMP MIBs, taking advantage
of 10,000+ managed objects. Currently depends on SNMP protocol for
monitoring, which is widely deployed. 
Disadvantages: It is a new protocol not supported on most existing hardware;
no hard data about how robust or useful it is as a protocol. The PIB
approach is a new mechanism and there is no hard data about how robust or
useful it is for expressing policies. The integration between COPS/PR and
SNMP has not been fully specified, so applications will need to provide much
of the integration "outside" the two protocols. Since it builds upon SNMP
data modeling and depends on SNMP monitoring, it suffers all the
disadvantages of SNMP when doing data modeling and monitoring.

SNMPCONF:
Advantages: Uses existing SNMP protocol and architecture, with twelve years
as a widely-deployed, robust and useful protocol standard for monitoring;
lack of security in SNMPv1 has severely limited its use for provisioning.
SNMP protocol can be used in a polling-driven or event-driven approach
(typically it has been polling-based due to the unreliability of SNMPv1/UDP
traps). Able to provision SNMP MIBs, taking advantage of 10,000+ managed
objects. Uses SNMP both for provisioning and monitoring, so data is fairly
easily correlated.
Disadvantages: Depends on an administrator developing policies using a
scripting language that is the amalgum of multiple existing languages.  This
new programming language is not supported on existing devices, and has no
hard data about how robust or useful it is for expressing policies. Since it
builds upon SNMP data modeling and depends on SNMP for provisioning and
monitoring, it suffers all the disadvantages of SNMP when doing data
modeling and provisioning or monitoring.

There are differences in security: 
SNMPCONF ties into SNMPv3 security, which is not widely deployed, but which
addresses user-based authentication and administrator configurable
authorization. Encryption provides a tunnel between the manager application
and the agent. The integration of the division of responsibility between
SNMPCONF policies and SNMPv3 access control has not been clearly defined,
although the same administrators are likely to write the policies and
configure the access control.
COPS/PR security depends on IPSec, which uses host-based authentication.
IPSec encryption typically provides a tunnel between the host running the
manager application and the device running the agent. The host-based
approach may or may not be adequate depending on the division of
responsibilities in an organization. Authorization to manipulate
provisioning data depends on clearly separated responsibilities of clients
that may be produced by different vendors; different vendors may divide
responsibilities differently making it more difficult to write
vendor-neutral policies. The integration of the division of responsibility
between COPS/PR policies and SNMPv3 access control has not been clearly
defined; COPS/PR division of responsibility is largely
client-vendor-dependent, while SNMPv3 access control is configured by the
network administrator.

I'm sure both sides will find fault with my analysis. You'll need to do your
own analysis to determine how they compare for the purpose to which you want
to put them. Hopefully my suggestions will give you some idea of the things
to look at more closely.

dbh
---
David Harrington            
[email-masked]           
co-chair, IETF SNMPv3 WG

> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 1:49 PM
> To: Durham, David; 'Tricha Anjali'; [email-masked]
> Cc: Ian F. Akyildiz

---

From: "Kulkarni, Amol" <[email-masked]>
Date: Mon, 25 Feb 2002 16:50:22 -0800

David,
 
I'd like to add to/correct some of what you said about COPS-PR security. 
 
COPS-PR security is not restricted to IPSec. In fact, the draft 'COPS over
TLS', which has passed last call, describes how TLS can be used to secure
COPS.
 
Amol
 
-----Original Message-----
From: Harrington, David [mailto:[email-masked]] 
Sent: Monday, February 25, 2002 12:20 PM
To: 'Tricha Anjali'; [email-masked]; snmpconf@snmp. com (E-mail)
Cc: Ian F. Akyildiz
Subject: RE: COPS vs. SNMP
 
Hi Tricha, 

> From: Wijnen, Bert (Bert) [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Durham, David [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > http://www.internetwk.com/story/INW20020213S0002
<http://www.internetwk.com/story/INW20020213S0002>  
> > > From: Tricha Anjali [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > Any help will be appreciated! 
<http://users.ece.gatech.edu/~tricha/>

---

From: "Durham, David" <[email-masked]>
Date: Mon, 25 Feb 2002 17:41:33 -0800

Hi Tricha,

I think I forgot to address your second question. Yes, resource reservation
in a network can be achieved via COPS. Its primary advantage over SNMP is
that it was designed with this specific purpose in mind. Specifically:

* COPS-PR supports a completely transactional model:
	o Messages represent atomic transactions. 
	o All parts of a transaction either succeed or fail.
	o On failure, the device automatically rolls-back to its last
operational state.
	o The server can also quickly switch between provisioned contexts
(eg. from day policies to night policies).
	o Failures and errors are very precisely reported PEP to PDP.
	o Supports large transactions.
	o Implementations do not worry about caching random attributes
waiting for a complete transaction (as is a problem for SNMP), everything in
the transaction comes at once in one message.
* COPS-PR supports structured row-level access:
	o A row represents an atomic unit for data communication.
	o There is no need for rowstatus, owner strings and the like.
	o A row is essentially an indivisible structured data type.
	o OID data is sent only once per row, representing a 10x gain in
on-the-wire efficiency over SNMP for e.g. a packet classifier filter w/ 10
fields.
* COPS-PR supports multi-manager control without the danger of corruption:
	o Each PDP has its own data instance space on the PEP which cannot
be manipulated by other PDPs.
	o PDPs data instances are isolated by the message-level client-type
field.
* Completely event-driven:
	o There is no polling in COPS-PR. 
	o PEPs notify PDPs only when there is something to report and vice
versa.
	o Persistent TCP connection means no 3-way handshake overhead for
messages.
	o TCP heartbeat verifies aggregate communication over the connection
and confirms operational status.
* Multiple Levels of security:
	o COPS intrinsically provides message-level integrity with PEP and
PDP authentication.
	o COPS over TLS provides additional level of authentication and
private communication.
	o IPSec provides yet another level of authentication and privacy. 
	o ... All communication is secure before the first COPS-PR message
is even exchanged. 	
* Object-Oriented Data Model and Data Definition Language.
	o COPS-PR via the SPPI improves the state of the art over the SNMP
SMI.
		- Allows inheritance of data structures.
		- Allows typed references.
		- Allows structured containment.
		- Allows typed associations.
		- Allows typed groupings.
		- Adds support for Integer64 and other basic data types.
		- Maximizes reuse of data definitions.
	o Via the framework PIB provides a data model that can be
reused/shared across PIBs for common/redundant policy functions and
definitions.
	o All new PIB definitions can integrate with existing PIB
definitions to add features and capabilities.
	o Common data-path theme throughout COPS-PR PIBs.
* Capabilities Reporting:
	o COPS-PR via the framework PIB provides a mechanism by which the
PEP clearly yet generically describes what PIBs and parts of PIBs it
supports.
	o Both semantic and syntactic capabilities are generically
communicated PEP to PDP.
* COPS-PR integrates event outsourcing and provisioning:
	o Eg. when an RSVP message is signaled & outsourced PEP-PDP, a
diffserv provisioning policy can be pushed down.
	o Integrated provisioning and outsourcing can be accomplished over
one message RTT.
	o Policy usage information can be used to signal a policy change.
* COPS provides built-in synchronization and failover:
	o PEP automatically moves to backup PDPs on failure.
	o PDP quickly synchronizes state with PEP after communication
failure.
		- Quick last transaction ID verifies PEP state.
		- PDP can resynchronize all or any selected state.
	o Enables quick TCP session recovery.
* COPS-PR inherently was designed to run over reliable transport via TCP.

Well, anyway, these are some of the main reasons for COPS-PR that come to my
mind.

Cheers,
-Dave

---

From: "Durham, David" <[email-masked]>
Date: Tue, 26 Feb 2002 18:13:11 -0800

Comments inline...

> From: David Partain [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 4:03 AM
> To: Durham, David; 'Wijnen, Bert (Bert)'; [email-masked]
> Subject: Re: COPS vs. SNMP
>
[DaveD] ...

> 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.
> 
[DaveD] The issue is two fold, 1. if the installed base of
protocol/implementations for whatever reason are being shut-off, then who
can do configuration management with SNMP? 2. Somebody should take a close
look at running local scripts to do policy control, specifically in the
context of SNMPConf... I've brought this up before, the CERT advisory is a
nice reminder to make sure some up-front attack prevention is done or at
least considered. Clearly defining the division of responsibility between PM
policy and SNMPv3 access-control would be a nice place to start.

> bw> The SNMP CERT advisories have NOT talked about a flaw
> bw> in the SNMP Protocol at all. They have talked about implementation
> dd> Perhaps,
> 
> It's not a question of "perhaps".  It's absolutely certain.
> Please read the advisory.

[DaveD] The advisory is not clear in this regard, I read it. Also, the press
reports clearly specify  that there are Vulnerabilities in the SNMP
Protocol. It was not clear if this was based ONLY on the cited CERT
advisory.
> 
> 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.

[DaveD] Ummm, the protocol can make it more difficult for implementations to
get it right. Eg. XML provides nice begin tags and end tags. Or better yet,
fixed size fields are easier to implement than allowing everything to vary.
Allowing fields to vary (via the spec) within bounds specified with a lower
bound of MUST and an upper bound of SHOULD also adds to the complexity for
implementers.
> 
> dd> COPS and COPS-PR security mechanisms are NOT BER-based.
> 
> It has absolutely nothing to do with security mechanisms.
> It's buffer overflows.

[DaveD] If the protocol uses the BER encoded security mechanisms, and the
BER encodings are susceptible to buffer overflows,  then you can obviously
directly attack a machine through the BER encoded security mechanism itself!

> 
> 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.

[DaveD] ... And I forgot to point out that the SPPI promotes better type
checking as well, and removes the need for those long, composit-INDEX OIDs
altogether. Keeping things easy for implementers is a good thing here!

---

From: "Harrington, David" <[email-masked]>
Date: Tue, 26 Feb 2002 21:48:14 -0500

> [DaveD] The advisory is not clear in this regard, I read it. 

What is not clear about this text from the advisory?
"Numerous vulnerabilities have been reported in multiple vendors' SNMP
implementations."
[Oulu] "has reported numerous vulnerabilities in SNMPv1 implementations."

> Also, the press

So we look to the press to provide us protocol designers with solid
technical information now? Oh my! 

I hope COPS wasn't designed by the journalists.... ;-)

As far as the recommendation to disable SNMP, the advisory reads:
"As a general rule, the CERT/CC recommends disabling any service or
capability that is not explicitly required, including SNMP." So, using your
logic, if I have devices that don't need COPS/PR, then COPS/PR must not be
suitable for provisioning?

Get a clue. Understand what the CERT advisory is about before you try to use
it to justify COPS/PR.

I expected better from you.
dbh

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks

---

From: "Glenn Waters"<[email-masked]>
Date: Wed, 27 Feb 2002 10:04:46 -0500

Dave, the CERT advisory is purely about SNMP implementations and it not in
any way about the design of the SNMP protocol.

The types of implementation problems that have been identified are pretty
much all buffer overflow problems. When a buffer overflow occurs the box
will typically exhibit some bad behavior -- like crash. This is known as a
denial of service attack. Some smart hackers have even put assembled byte
code in the overflowed buffer in an attempt to get that code to execute. In
this case, the hacker could possibly take control of the box.

If you remember your Internet history, many years ago the SMTP protocol was
used to compromise a system. This also made the news big time. I would
characterize the SMTP protocol encoding to be even simpler than COPS-PR; to
which I conclude that COPS-PR is just as vulnerable as ANY other protocol.
Try the following goggle search and you see what I mean by the word ANY in
the previous sentence:

	http://www.google.com/search?hl=en&q=buffer+overflow 

/gww

-----Original Message-----
From: Durham, David [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2002 21:13
To: [email-masked]'; [email-masked]
Subject: RE: COPS vs. SNMP

Comments inline...

[DaveD] ...

---

From: "Durham, David" <[email-masked]>
Date: Wed, 27 Feb 2002 09:56:44 -0800

Hi Glenn,
 
I think there is a clear difference between COPS-PR & SNMP models regarding
the issue of security, particularly in light of this CERT advisory.
 
COPS-PR:
* The Network Devices initiate all communication with trusted PDPs via a TCP
session that can be secured at 3 different levels (COPS Message Integrity,
TLS, & IPSec).
 
* The Network Devices do not respond to any COPS TCP connection requests
coming in.
 
* Only once a secure TCP session is established and the COPS
clientopen/accept exchange do the devices communicate & receive data.
 
SNMP:
* SNMP UDP packets are asynchronously received by Network Devices pretty
much from anyone, anywhere.
 
* Since no session needs be established before hand, one shot SNMP UDP
packets can be sent & addresses can be spoofed.
 
* The devices need to start parsing the PDUs in each of these SNMP UDP
packets, and correct me if I am wrong, the PDUs are themselves BER
encoded... Even the SNMPv3 security mechanisms.
 
For the above reasons, it seems to me that the COPS-PR model is more secure,
particularly given BER seems to be hard to get right.
 
Cheers,
-Dave

-----Original Message-----
From: Glenn Waters [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 7:05 AM
To: [email-masked]
Cc: Durham, David
Subject: RE: COPS vs. SNMP

        http://www.google.com/search?hl=en
<http://www.google.com/search?hl=en&q=buffer+overflow> &q=buffer+overflow 

/gww

---

From: "Hahn, Scott" <[email-masked]>
Date: Wed, 27 Feb 2002 10:46:25 -0800

While I find this discussion interesting, I think a discussion about
potentially security problems in SNMP should be moved to one or all of the
SNMP mailing lists.

	-Scott Hahn
	RAP WG co-chair

-----Original Message----- 
From: Durham, David [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2002 21:13 
To: [email-masked]'; [email-masked] 
Subject: RE: COPS vs. SNMP 
Comments inline... 
[DaveD] ...