Subject: snmpconf RE: COPS vs. SNMP

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

> -----Original Message-----
> 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
> Subject: RE: COPS vs. SNMP
> 
> 
> 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,
> > > 
> > > 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: Wes Hardaker <[email-masked]>
Date: Tue, 26 Feb 2002 07:15:03 -0800

>>>>> On Mon, 25 Feb 2002 15:19:43 -0500, "Harrington, David" <[email-masked]> said:

[the majority of an *excellent* summary deleted]
David> SNMPCONF:

David> Disadvantages: Depends on an administrator developing policies
David> using a scripting language that is the amalgum of multiple
David> existing languages.  This new programming language is not
David> supported on existing devices, and has no hard data about how
David> robust or useful it is for expressing policies. Since it builds
David> upon SNMP data modeling and depends on SNMP for provisioning
David> and monitoring, it suffers all the disadvantages of SNMP when
David> doing data modeling and provisioning or monitoring.

one more: It pushes an awful lot of complexity out to the deployed
devices.  Specifically, if it is intended that the scripts written are
to be run directly on the device then every device must have a script
interpreter within it.

David> There are differences in security: 
...
David> COPS/PR security depends on IPSec, which uses host-based
David> authentication.

I think COPS/PR relies on an external method of protection, but is not
limited to just IPSec (if my understanding is correct) and thus you
could use something like TLS as well.

-- 
Wes Hardaker
NAI Labs
Network Associates