Subject: [dhcwg] Re: draft-bakke-dhc-snmp-trap-00.txt

From: Mark Bakke <[email-masked]>
Date: Mon, 16 Sep 2002 14:22:30 -0500

Here's another try at the snmp notification option for DHCP.  It's
not a formal draft; just a rough idea of what it might look like.
If this seems to be the right approach, I'll issue another revision
of the draft.

I also changed this from a binary structure to a text format, since it
needed to be fairly flexible.

--
Mark

DHCP snmp-trap-host option

Here's a quick sketch of what the new trap-host option could
look like.  I realize I need to add better detail in the
final draft.  This list of configuration attributes is from
RFC 2573 appendix A, which lists trap configuration examples.
I'm assuming that in a DHCP environment, that the only address
domain supported is UDP.  I've also assumed that some other
configuration info must exist to make the security name
meaningful, but that this information does not belong directly
in a list of notification hosts, and might be placed in some
other, more general SNMP configuration option.

snmp-notification-list option is a UTF-8 string consisting
of a comma-separated list of notification targets.  Each
notification target is a colon-separated list of parameters
in the following order:

<proc-model>:<addr>[:<security-params>]

<proc-model> is a decimal field which must match one of the
message processing model values defined in RFC 2571 in the
SnmpMessageProcessingModel TC:

   0 - SNMPv1
   1 - SNMPv2c
   2 - SNMPv2u and SNMPv2* (I'm not sure what this is for)
   3 - SNMPv3

<addr>

   This is the IP address and UDP port number of the target.  I
   wouldn't expect anyone to set up SNMP notifications over a non-IP 
   protocol such as OSI or DDP using DHCP, so I didn't include a domain.
   We could add it back in if there's good reason.

   IPv4 addresses are specified as dotted decimal with optional port:

   nn.nn.nn.nn/port

   Example: 10.1.50.100/162

   with the "/port" optional.

   IPv6 addresses are specified as a bracketed hexadecimal address,
   as specified in RFC2732, followed by the optional "/port".

   Example: [1080:0:0:0:8:800:200C:417A]/162.

<security-params> is optional and depends on the processing model used.

For v1 and v2c, this consists of a community string

<community-string> - The community string to use when sending
   notifications to this target.  If not specified, the default
   is "public".

For v3, this specifies the security model and its paramters, and
consists of:

   <security-model>:<security-level>:<security-name>

<security-model>

   This is the security model number from the RFC 2571 SnmpSecurityModel
   TC.  The current (decimal) values are:

   1 - SNMPv1
   2 - SNMPv2c
   3 - User-Based Security Model (USM)

<security-level>

   This is the decimal security level number as specified in the RFC 2571
   SnmpSecurityLevel TC:

   1 - noAuthNoPriv
   2 - authNoPriv
   3 - authPriv

<security-name>

   This is the UTF-8 security name to be used with notifications to this
   target.

Examples:

   A group of two v3 targets, both using USM with authentication but no
   privacy:

   3:128.1.2.3/162:3:2:joe,3:128.2.4.6/162:3:2:joe

   A single v3 target, using USM with both authentication and privacy:

   3:128.1.5.9/162:3:3:bob

   A single address that wants both v1 and v2c notifications with the
   default community string and UDP port:

   0:10.1.1.1,1:10.1.1.1

   An SNMPv2 address that uses a different community string:

   1:10.50.2.100:my-community

BTW, using 0 for v1, 1 for v2c, and 3 for v3 is confusing, and these
strings have to be typed in by DHCP adminstrators.  We could go with
text tags "v1", "v2c", and "v3" instead for message processing
models, and allow "usm" for the security model as well:

   v3:128.1.2.3/162:usm:authNoPriv:joe,3:128.2.4.6/162:usm:authNoPriv:joe
   v3:128.1.5.9/162:usm:authPriv:bob
   v1:10.1.1.1,v2c:10.1.1.1
   v2c:10.50.2.100:my-community

Any preferences?
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Harrington, David" <[email-masked]>
Date: Sun, 15 Sep 2002 23:12:26 -0400

Hi Mark,

The bulk of the current usage of SNMP is for monitoring, not configuring.
There are few mib objects that would require dynamic configuration. However,
it could be a very interesting discussion to start with the SNMP community
via the SNMPv3 list.

We're trying to wrap up and close the SNMPv3 WG. I think the discussion
would need to move to a different forum, but which forum depends to a large
degree on nature of the proposals that might come out of the discussion.

dbh

> -----Original Message-----
> From: Mark Bakke [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 4:42 PM
> To: Harrington, David
> Cc: [email-masked]'
> Subject: Re: draft-bakke-dhc-snmp-trap-00.txt
> 
> 
> David-
> 
> Thanks for the advice.  I just had a chance to go over 2571, 
> 73, and 74, and
> I think I can take a better shot at this (at least the 
> notification part).  I'll
> post to both dhcwg and the snmpv3 lists.
> 
> As far as the scope for this, I was initially just setting out to do
> enough for notifications.  Do you think that there is interest in
> configuring other agent parameters as well?
> 
> -
> Mark
> 
> > "Harrington, David" wrote:
> > 
> > Hi Mark,
> > 
> > RFC1448 is a remnant of the obsolete SNMPv2 specs. Nobody 
> supports the old RFC144x specifications.
> > You should be using SNMPv3 specifications. The most current 
> RFCs are 2570-2580, and approved
> > updates are in the editor's RFC queue.
> > 
> > RFC2573 defines a number of mibs that can be configured to 
> identify notification targets. If you
> > examine those mibs, you will find that there is more 
> information needed than just an address.
> > Therefore, your proposed message would need to contain more 
> to centrally configure SNMP targets
> > properly.
> > 
> > dbh
> > 
> > David Harrington
> > co-chair SNMPv2 WG
> > Network Management Architect
> > Office of the CTO
> > Enterasys Networks
> > 
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054
>

---

From: Mark Bakke <[email-masked]>
Date: Fri, 20 Sep 2002 13:11:46 -0500

David-

I'm copying the [email-masked] list on this as well; is it
sufficient?  Should I not send this to snmpv3?

Thanks,

Mark

> The bulk of the current usage of SNMP is for monitoring, not configuring. There are few mib
> objects that would require dynamic configuration. However, it could be a very interesting
> discussion to start with the SNMP community via the SNMPv3 list.
> 
> We're trying to wrap up and close the SNMPv3 WG. I think the discussion would need to move to a
> different forum, but which forum depends to a large degree on nature of the proposals that might
> come out of the discussion.
> 
> dbh
>