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:dbh@enterasys.com]
Sent: Monday, February 25, 2002 12:20 PM
To: 'Tricha Anjali';
rap@ops.ietf.org; snmpconf@snmp. com (E-mail)
Cc: Ian F. Akyildiz
Subject: RE: COPS vs. SNMP
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
dbh@enterasys.com
co-chair, IETF SNMPv3 WG
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, February 25,
2002 1:49 PM
> To: Durham, David; 'Tricha
Anjali'; rap@ops.ietf.org
> 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:david.durham@intel.com]
> > Sent: Monday, February
25, 2002 7:32 PM
> > To: 'Tricha Anjali';
rap@ops.ietf.org
> > 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:tricha@ece.gatech.edu]
> > > Sent: Monday,
February 25, 2002 9:38 AM
> > > To: rap@ops.ietf.org
> > > 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/
> > >
> > >
> > >
> > >
> >
>