On Tue, 2005-08-23 at 10:58 +0200, Thomas Anders wrote: > Dave Shield wrote:
> > I'm wondering whether we need to support a "wildcard" > > engineID mechanism. > I don't think we should do this, because it doesn't seem > to match the intention of the RFCs. It probably doesn't, no. But that probably says as much about the deficiencies of the USM framework in regard to "site-wide authentication" as it does about the idea of wildcarded user matching. > Wes (I think) has written up an excellent summary here: > > http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html That describes how things currently work, yes. But it relies on knowing the remote engineIDs in advance. That's not too much of a problem when you've got a small number of trap generators, and the engineIDs are stable. But it doesn't scale very well to a large network, where a single trap receiver might be working with hundreds or thousands of nodes. And it *definitely* doesn't work very well with the "random engineID" approach that the Net-SNMP library uses. Try running an SNMPv3 snmptrap command three or four times (*without* using the -e options), and examine the PDUs that are sent. There'll be a different engineID each time. Forcing a fixed engineID is certainly a way around this, but it feels something of a hack. Hence the suggestion of a wildcard match. Wes - this is much more your area of expertise than mine. Care to comment? Dave ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
