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

[Mark Bakke <[e-mail]>]

"Wijnen, Bert (Bert)" wrote:
> 
> So it seems you did not think about it in detail.
> What I hate to see is a partial solution to jsut the trap
> handling. That is what the IPCDN (cable modem folk) seemed
> to be doing too... and I pushed back on that (partial)
> solution too. I do not have a answer ready...
> 
> First question would be: is it a generic problem that people face?

Yes.  There are increasingly more solutions that allow hosts,
racks of servers, embedded devices, etc. to be booted from
the network.  When this fails, the host's normal configuration
info (particularly the SNMP notification list) is not available,
so there's no good way to tell a management station about it.

I assume that most networks would want to use SNMP for this,
but syslog would work as well.

> 
> Second question: what is the complete scope of the problem?

My personal complete scope is to set a notification list for
SNMPv1 and v2c hosts, with v3 a possibility in the future.
Since this is used only for notifications, I assume that
supporting v3 authentication would be a good idea (so
notifications are not spoofed) but that privacy is probably
not that much of an issue (but again, may need to be there
for completeness).  

> Third question: what would be a good/feasable/workable solution?

However, it may not be possible to configure enough of the
security stuff securely (did I say that right) using DHCP
to actually make use of v3 security.

If that's the case, there could be a compromise:

- Configure the list of v1, v2c, and v3 notification targets
  as I had proposed, with only the security name (and not the
  keys) in the v3 target strings.
- During boot, if a notification needs to be sent, and the v3
  security parameters are not yet known for a target, skip
  that target, but still send to the others in the list (such
  as the v1 and v2c targets).
- Once the host has booted far enough so the security parameters
  are known (through its normal configuration), include the v3
  targets in any notifications.

This means two scenarios can happen:

1. A host, during boot, only sends v1 and/or v2c notifications
   without security.  Once it's up and running, notifications
   include v3 targets, too.

2. A host has v3 username-to-security-parameter settings in its
   non-volatile configuration.  These are available during boot,
   and can be associated with a notification target from DHCP
   by its security-name.  This might be the best direction to
   go for the future; have security keys in the machines, and
   the actual targets for notification controlled centrally via
   DHCP.

I think this would be a reasonable solution, given that it's
probably not practical to configure the security keys for a host
using DHCP.

Does this help?

--
Mark

> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Mark Bakke [mailto:[e-mail]]
> > Sent: maandag 23 september 2002 15:55
> > To: Wijnen, Bert (Bert)
> > Cc: '[e-mail]'; snmpv3@lists. tislabs. com (E-mail);
> > [e-mail]
> > Subject: Re: draft-bakke-dhc-snmp-trap-00.txt
> >
> >
> > I assumed that, when we get to configuring SNMPv3 security,
> > that the names "joe" and "bob" would be separately associated
> > with their keys.  I wanted to keep this particular DHCP
> > option scope to include the notification list, and the names
> > would reference keys configured somewhere else (perhaps another
> > DHCP option, but since I haven't seen encrypted DHCP, this
> > might not work).  In other words, I don't know, but I think
> > that if it was DHCP, it would be better as a separate option.
> >
> > Any ideas?
> >
> > "Wijnen, Bert (Bert)" wrote:
> > >
> > > So in your new proposal, how did/do users Joe and Bob get
> > > defined with their secret keys etc at the agent side?
> > >
> > > Thanks,
> > > Bert
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > [e-mail]
> > 763.398.1054
> >
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg

-- 
Mark A. Bakke
Cisco Systems
[e-mail]
763.398.1054
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg