David,
thanks for your continued interest.
On a system (and there can be 10s of thousands of them),
that right before a notification is sent as an inform,
that the system contacts another system and that system
adds a USM table entry to the agent associated with the
notification receiver (via SNMP sets) (and also adds
an entry in the "to Group" table, and I assume the
VACM access and view tables are already set up and
don't need to be updated).
Quite correct. Let's call the "10s of thousands of systems" devices. The
management system consists of a Kerberos entity and a SNMPv3 entity.
Individual SNMPv3 USM entries get negotiated (derived) between the
Kerberos entity and the device in at least a 4-step Kerberos
AS-REQ/AS-REP/AP-REQ/AP-REP sequence and then passed from the Kerberos
entity to the SNMPv3 entity. (This is what we need the feature in
question for.) Then the device sends a SNMPv3 INFORM to the SNMPv3
entity (which now needs to have the USM entries in place) which then
(and later on) configures the device using SNMPv3 SETs.
For more details refer to the "Kerberized SNMPv3 Key Management" chapter
in http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf.
I couldn't tell what security
level you were using. I couldn't tell if you make these
USM and ToGroup entries persistent (and reuse them).
authPriv. The USM entries for a device are persistent until new ones get
negotiated again (initiated by either the device or the management system).
Is it correct that the USM and ToGroup tables will
then contain 10s of thousands of entries?
Yes.
How often are entries added, removed, or updated
in the USM and ToGroup Tables?
Whenever a device powers up or the management system decides to
re-negotiate keys. Potentially, *all* devices could come up "at once"
(i.e. within minutes).
What security level is being used on
a) creating the USM entries
b) sending the informs
Both authPriv, although the security level for b) is negotiated between
the device and the management system. This will result in authPriv if
forced from the management system side (which is done here).
How are the keys transmitted to the managed systems
sending the informs (if a security level other than
noAuthNoPriv is being used)?
Kerberized Key Management. See above.
OTOH, the above may not be the only application for online snmptrapd USM
user management, I think. Still an interesting case study, though. :-)
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
