HI, I'm going to reply a little later with my findings, and recomendations for changes. However, I'm going to <soapbox> In USM users are qualified by engineID. User "joe" with engineID <eid_1> is different from user "joe" with engineID <eid_2>. In USM, the engine and user name are contained in fields msgAuthoritativeEngineID and msgUserName of UsmSecurityParameters, which is the USM specific format for field msgSecurityParameters of SNMPv3 messages. Other security models may have different formats and values for field msgSecurityParameters.
Since SNMPv3 messages are between two engines (which have different engineID values), and there is a single place in UsmSecurityParameters to put an engineID, there is a question as to which one. USM (not SNMPv3) solves this by using the following (and I think INAPPROPRIATE) rules: for requests (such as GET, SET, etc) and INFORMs (and the responses to them), the engineID is that of the receiver of the request (and INFORM). However for TRAPs, the engineID is for the sender (the "notification generator"). This seemed fine, but operationally it is troublesome because each pair of notification generator and receiver must have a pair of entries per user - one with the generator's engineID (for TRAPs), and one for the receiver's engineID (for INFORMs). This "feature" was added at the "last moment" to "solve the problem of clock synchronization". It turns out that in the UsmSecurityParameters value, there are also fields msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime, which are used to help determine is a message has been excessively delayed or replayed. Originally, the engineID (and clock) in an INFORM was that of the notification generator. AND THIS REALLY DOES WORK. However, the response to an INFORM back to the generator also has the generator's clock values. It was argued that what is the generator suppose to do with the clock value (since it was authoritative). Thus the change, but with MANY unanticipated COSTS! So, today with USM, we have what I believe is a totaly broken model. I'm going to skip details in the remaining.... Today, we have software the doesn't remember engineIDs and associated clocks. So every time a request or INFORM is sent, it must do "engineID discovery". So, when INFORMs are used instead of TRAPS, there are 4 SNMP messages on the wire instead of just 1. So, I don't consider that using INFORMs is the way to go in all situations. </soapbox> And now another about the NET-SNMP implementation (but I know that many people do this on their "own time", so please, I appreciate, but there can be some small changes that yield great benefits) <soapbox> Now, on NET-SNMP, what I find most troubling is the inconsistent behavior between SNMPv1(and v2c), and SNMPv3/USM, and between TRAPs and INFORMs. First, when encryption is being used, you have got to have the encryption/decryption keys to be able to read (the PDU of a) message. And you can tell (from hieristics) whether or not you have a valid encryption/decryption key. And to have one, you must have a engineID and user entry! But on the other hand, you can process authenticated and unauthenticated SNMP messages WITHOUT keys or user entries or community entries. So here is the inconsistent behavior.... NET-SNMP snmptrapd receives and processes SNMPv1 (and v2c) TRAPs and INFORMs (v2c only) without having community strings configured. But you must have users configured for snmptrapd to process USM TRAPs and INFORMs. And, if on the same machine you run snmptrapd and snmpinform, then you only need a createUser in the snmptrapd.conf, and snmpinform "works", but snmptrap doesn't work. I would hope for the following changes for USM: 1) with no users configured, you should be able to recieve both noAuthNoPriv TRAPs and INFORMs (but maybe the output should be marked) 2) on authNoPriv TRAPs and INFORMs, if there is a problem (user doesn't exist, authentication failure, "out of window" when not doing engineID (and clock) discovery) then I believe that the notification should still be outputted (but marked with the failure) reason 3) on authPriv and a failure, an output should still be done, but with an error indication that the message content is not available. (there is still available the values from UsmSecurityParameters. </soapbox> Regards, /david t. perkins On Tue, 23 Aug 2005, Thomas Anders wrote: > Dave Shield wrote: > > 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. > > Isn't this already solved today by using SNMPv3 INFORMs instead of > TRAPs? The single trap^H^H^H^Hnotification receiver is supposed to > *have* a persistent engineID and the notification generators just need > to be configured appropriately once. Not to mention the additional > benefit of INFORMs vs. TRAPs. Am I missing the problem here? > > > +Thomas > > -- > Thomas Anders (thomas.anders at blue-cable.de) > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
