Subject: Re: [MIB-DOCTORS] SNMP For configuration

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 May 2010 13:43:41 +0200

MIB Doctors,

Here is a dialog that your AD's are entertaining, started by Ron who is
asking whether time has come for a statement that discourages write
operations using SNMP.

Your input is welcome. 

Dan

> Does anybody actually use SNMPv3 to configure a router? If so, how do
they do simple things like provision a static route?

                                Ron

On 4/25/2010 7:14 AM, Romascanu, Dan (Dan) wrote:
> Ron,
> 
> I do not think that the time for a general across the board statement
> has already come. We do not have a protocol + data modeling language
in
> place yet to make such a recommendation, and in some environments the
> usage of SNMPv3 (we strongly recommend not to use prior versions in
> general and for write operations in particular) may continue for a
> while. In the case of RFC 4807 there is quite strong language on this
> respect in the Security Considerations section, but if we believe that
> this is not sufficient we can update the document.  
> 
> Dan
> 
>> -----Original Message-----
>> From: Ron Bonica [mailto:[email-masked]] 
>> Sent: Friday, April 23, 2010 5:17 PM
>> To: Romascanu, Dan (Dan)
>> Subject: SNMP For configuration
>>
>> Dan,
>>
>> I have a customer who is requesting full RFC 4807 support. 
>> RFC 4807 includes some read-write and read-create objects, as 
>> if they expect MIB to be used for configuration.
>>
>> Is it time for the IETF to issue an RFC saying that SNMPv* 
>> isn't adequate for configuration, especially for security 
>> related features like IPSEC?
>>
>>                                             Ron
>>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 May 2010 14:00:40 +0200

> they do simple things like provision a static route?

Even if nobody uses SNMP to configure routers, the conclusion can't be
to discourage write operations using SNMP in general. A while ago, I
proposed to retire COPS-PR and got pretty interesting responses for
that. I think Ron should write an ID and then we can take it from
there. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 10 May 2010 08:46:19 -0400

Hi,

I STRONGLY object to a statement discouraging MIB module developers
from using writable objects.

I used to work for a vendor (Cabletron/Enterasys) that produced a
number of prodycts that depend on SNMP writes.

The primary protocol used in a leading enterprise-based network
management product was SNMP.
The product was used to discover and visually map the network, and the
traffic passing on that network.
It tour-de-force was root cause analysis for faults and performance
issues.
But it didn't just monitor the network; it manipulated the devices in
the network.
And it required write access to do this manipulation.

It disabled ports when an operator requested such a device change.
It disabled ports when a port was behaving problematially, whether due
to misconfiguration or malicious traffic. 
It disabled ports in responses to requests from our Intrusion
Prevention System.
It adjusted port speeds and other parameters as requested by an
administrator interactively or by policy.

The product also supported an API for vendor-provided, VAR-provided,
or customer provided applications.
Such applications allowed classroom access to the Internet to be
blocked during the teaching session, but opened during class "lab"
sessions where the students used the Internet for research purposes.
Applications supported case-based-reasoning, where certain thresholds
or other events would trigger automated policies that modified device
configurations.

If a device had RMON support, that could be used to monitor certain
types of traffic and relationships.
RMON, of ocurse, requires you to be abel to write to the RMON tables
to configure such monitoring.
The product could ping a remote device from another remote device to
determine if another path was live, when the path from the product to
the device appeared dead. It did this using MIBs.

We also offered an ATM application, new defunct, that configured
physical and virtual paths with different attributes for quality of
service. These were all configured using MIBs.

The company also depended on SNMP writes to make their hardware
products manageable.

The company's hardware products were configured using configuration
files, but the devices were configured to know the locations and names
of configuration files and the protocols that could be used to access
them and what the files should be named after download to the local
system. Multiple configurations coould be stored on a device. A file
could also be manipulated on the device after download using certain
predefined operations, by manipulating MIB objects to trigger the
operations. All done using SNMP writes.

Certain information on devices is typically set during manufacturing,
but might be manipulated afterwards for various reasons. Changing the
MAC address, changing the apparent vendor name for OEM products, etc. 

For various L2 products (which may no longer exist), certain
parameters of operation could be enabled/disabled or otherwise
manipulated: Spanning tree algorithms, broadcast storm control, IGMP
snooping, multicast storm controls, 802.3 flow control, etc. Some
products supported multiple emerging standards, and an operator could
choose which of various alternatives should be enabled (and which
disabled) when the system rebooted.
MIB objects could control the snap-shot of a configuration and its
transfer to remote locations, when certain paraeters were saved to
NVRAM, priority queueing algorithms/weights/etc., address filtering,
logical port trunking, VLAN management, etc.

At other layers, writable MIB objects allowed
configuration/manipulation of certain features, such as the SSH
server, syslog capability, rate policing, vlan priority
classifications, MAC locking (similar to 802.1X).

These writable MIB objects were supported, to varying degrees, in
element and network management applications developed by the company
and by third parties. 

So to me, thinking that SNMP writes would be useful for full-device
configuration is missing the point of SNMP, and why a write capability
is critically important to SNMP, and writable objects are important in
MIB modules.

I STRONGLY object to a statement discouraging MIB module developers
from using writable objects.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Monday, May 10, 2010 7:44 AM
> To: Ron Bonica; MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] SNMP For configuration
> 
> 
> MIB Doctors,
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 May 2010 08:46:43 -0700

> from using writable objects.

Although I do not think SNMP will ever be widely
deployed for CM, I don't think there is sufficient
reason to officially discourage its use.

Instead, when YANG is published, the IESG should
encourage the use of NETCONF and YANG for CM.

Andy

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 10 May 2010 14:23:17 -0400

Ron,

I've seen (and worked for) several equipment vendors
that support SNMPv3 for configuration, BUT do allow
customers the option of turning off the
configuration via SNMPv3, if they so choose.
Customers have been satisfied with that.

Additionally, WGs can (and do) produce MIBs that
don't support read-write/read-create.   If MIBs do support
configuration, there is typically a compliance statement in the MIB
for read-only, so in other words, implementors that don't support
configuration will still be compliant with the MIB document (RFC).

So, in my opinion, I don't see the need for an official statement that
discourages the use of SNMPv3 for configuration at this time.

Thanks,
  -Joan

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: "'MIB Doctors (E-mail)'" <[email-masked]>; "'Ron Bonica'" 
<[email-masked]>
Sent: Monday, May 10, 2010 11:46 AM
Subject: Re: [MIB-DOCTORS] SNMP For configuration

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 May 2010 11:35:05 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Ron Bonica" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Monday, May 10, 2010 4:43 AM
...
> asking whether time has come for a statement that discourages write
...
> >> related features like IPSEC?

No, if your customers are asking for it, it's time to consider implementing it.

Before you deprecate the use of SNMPv* for configuration, you'd better
be sure that standardized yang/netconf models that are at least as functional
are in place.  The experts in that area are still arguing about whether "get" and
"create" should do the same thing in different implementations, so I am
pessimistic about those standardized models being completed any time
soon, much less coming into such wide deployment as to justify a
recommendation against the use of SNMP for configuration.

Randy

---

From: Ron Bonica <[email-masked]>
Date: Mon, 10 May 2010 16:15:13 -0400

Joan,

Are any of these vendors still producing these products? If so, I will
back off.

                               Ron

On 5/10/2010 2:23 PM, Joan Cucchiara wrote:
> .

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 12 May 2010 08:49:30 -0400

Ron,

Most routers today support ACLs and setting up ACLs to filter (deny)
SNMP SET requests would provide a similar solution, correct?

My point is that the flexibility exists to provide SNMPv3 configuration (or 
not)
for customers and WGs, so I don't see a compelling reason at this time for 
the
IETF to discourage SNMPv3 for configuration.

Thanks,
-Joan

----- Original Message ----- 
From: "Ron Bonica" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: "Andy Bierman" <[email-masked]>; "David B Harrington" 
<[email-masked]>; "'MIB Doctors (E-mail)'" <[email-masked]>
Sent: Monday, May 10, 2010 4:15 PM
Subject: Re: [MIB-DOCTORS] SNMP For configuration

---

From: "David Harrington" <[email-masked]>
Date: Wed, 12 May 2010 09:34:10 -0400

SNMP can be filtered at multiple points.

SNMP can be filtered at the ACL level, 
R/R traffic can be filtered while still allowng notifications

at the implementation level
	- if they write their own implementation, they can choose not
to support SETs

at the deployment level 
	- operators can usually choose to not enable SNMP if they
don't want SNMP at all 
	- operators can configure VACM to not allow anybody to do SETs

Most people who write MIB modules 
a) have experience and know that not every implementation supports
SETs
b) have experience and know that SNMP traffic is often filtered
c) have experience and write conformance clauses allowing for
read-only compliance
d) do not have experience and ask for help from, e.g., MIB Doctors or
experienced engineers

I see no benefit from telling people they SHOULD NOT use SNMP writes.
If somebody chooses to do configuration using SNMPv3, what is the
harm?

dbh

> [mailto:[email-masked]] On Behalf Of Joan Cucchiara
> Sent: Wednesday, May 12, 2010 8:50 AM
> To: Ron Bonica
> Cc: 'MIB Doctors (E-mail)'
> >>>>>> usage of SNMPv3 (we strongly recommend not to use 
> prior versions
> >>>> in

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 May 2010 09:42:11 -0400

Joan,

I may be all wet on this point, and if I am, please set me straight. But
it seems to me that it is very difficult to do some very fundamental
things using SNMPv3 configuration. For example, how would one add a
static route with a few attributes?

To the best of my knowledge, a few vendors have attempted SNMP
configuration. For the most part, those vendors are gone. Again, if you
can point at anybody who currently is using SNMPv3 for configuration in
a significant way, I will back off.

                                    Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 May 2010 16:25:33 +0200

> static route with a few attributes?

True, there are no decent MIB modules to configure IP routes. If you
go one layer below, the picture changes completely.
 
> a significant way, I will back off.

Some (well all those I have seen ;-) HP switches are very much SNMP
configurable; it seems even their CLI internally talks SNMP to their
backend engine. In the IEEE 802.1 space, SNMP writes are generally
much more common than they are at the IP layer or above. Also, RMON is
still out there as is SFLOW - both pretty much rely on SNMP for
configuration. There is likely much more to name - but you said one
example is enough.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 12 May 2010 10:26:06 -0400

I don't think anybody is recommending SNMP to do complete
configuration of a device (unless it's a simple device).
I don't think anybody is recommending that SNMP be the only protocol
used to do configuration.
But it certainly has its place in the toolkit, is widely deployed, and
has hundreds (thousands?) of applications, including homne-grown
scripts, that already work with it. 
I don't see the benefit from discouraging its current widely-deployed
usage, including writes.

Ron, you haven't said: what are you hoping to accomplish by
discouraging SNMP writes?

dbh

> [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: Wednesday, May 12, 2010 9:42 AM
> To: Joan Cucchiara

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 07:42:26 -0700

> a significant way, I will back off.

I doubt it is used in a significant way,
but there are plenty of spot-applications
that use SNMP Set.  I've implemented a couple
RMON probes and SNMP Set can be used to configure
the RMON monitoring control tables.

One can tell from all the different configuration type
of protocols that exist in the IETF, that the IESG is not
encouraging the use of SNMPv3 instead.

I am biased towards NETCONF/YANG of course, and hope that it
gains enough traction to become a real CM standard solution someday.
The hard part has always been getting all the vendors to
agree on configuration knobs, and in the NETCONF/YANG world,
we are trying to develop solutions that work even in the gray areas.

Andy

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 May 2010 11:35:33 -0400

> configuration. There is likely much more to name - but you said one

This explains my prejudice. Having lived at the IP layer for so many
years, I haven't seen many routers that are SNMP configurable. Had I
spent more time in layer 2, I would have seen more SNMP configurable
devices.

So, I will back off until netconf/yang are completed.

                                       Ron

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 May 2010 11:47:16 -0400

> discouraging SNMP writes?

David,

For the moment, permit me to speak as a vendor.

Every day, vendors respond to RFP's. RFPs list off requirements as follows:

RFC abc
RFC def
RFC xyz

Frequently, RFC abc is a MIB with writable objects. This puts us in a
bad spot. We have to say that we only partially support the requirement
even though it would be insane to fully support it. (Because the
operator couldn't completely configure the box using SNMP if even he
wanted to!)

Life would be easier if writable objects were never mandatory.

                                     Ron

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 May 2010 11:46:29 -0700

Hi -

> Cc: "'MIB Doctors (E-mail)'" <[email-masked]>
> Sent: Wednesday, May 12, 2010 6:42 AM
...
> a significant way, I will back off.

Cable modems.  There might be a few of those out there.  :-)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 May 2010 11:51:40 -0700

Hi -

> To: "David Harrington" <[email-masked]>
> Sent: Wednesday, May 12, 2010 8:47 AM
...
> Life would be easier if writable objects were never mandatory.

I see it differently.  The IETF's willingness to cave to these pressures
meant that there was little motivation to specify all the information
needed for realistic configuration, and even less to demand conformance.
A dysfunctional downward spiral.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 12:55:55 -0700

> A dysfunctional downward spiral.

I have a shred of hope left, because there really are valid
reasons why SNMP works much better for monitoring than it
does for configuration.  But there are also some issues
specific to configuration, and unrelated to the management
protocol.

For starters, multiple config schemes do not easily
play well together, unlike multiple monitoring schemes.
Since standards always lag proprietary solutions,
supporting the standard CM N years later is problematic.

Because of the additional complexity to support *any* standard,
we will likely hear the same 'cannot possibly replace the CLI'
excuse, even if NETCONF/YANG is deployed.

Andy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 12 May 2010 17:20:44 -0400

In most, if not all, standard MIBs, there are read-only compliance
clauses.
It is well understood that many SNMP implementations/deployments do
not support SET.
So most MIB modules allow compliance without making all writable
objects mandatory.
But for those who want to support writable objects, there is a
full-compliance clause.

dbh

> Sent: Wednesday, May 12, 2010 11:47 AM
> To: David Harrington
> Cc: 'Joan Cucchiara'; 'MIB Doctors (E-mail)'

---

From: "Flick, John W" <[email-masked]>
Date: Wed, 12 May 2010 21:54:24 +0000

Juergen is correct.  Our devices support SNMP configuration (and, yes, our CLI and web UI are actually SNMP applications that do everything through MIBs).  In the L2 switch space, SNMP configuration seems to be widely used, at least given the support requests we see from our customers.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 12, 2010 7:26 AM
To: Ron Bonica
Cc: 'MIB Doctors (E-mail)'
Subject: Re: [MIB-DOCTORS] SNMP For configuration

 

/js