Re: draft-bakke-dhc-snmp-trap-00.txt

[Mark Bakke <mbakke@cisco.com>]

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?