Moving to tech@ On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote: > On 2021/08/09 12:14, Martijn van Duren wrote: > > CVSROOT: /cvs > > Module name: src > > Changes by: [email protected] 2021/08/09 12:14:53 > > > > Modified files: > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c > > util.c > > > > Log message: > > Allow setting the engineid. > > > > The previous engineid was based aronud the engine boottime and a random > > value, which gives problems when sending/receiving unacknowledged PDUs > > (trapv2) over SNMPv3 with authentication enabled, which need a consistent > > engineid across restarts to determine the correct user from the sender. > > > > The new default engineid takes a sha256 hash (chosen for its longer output) > > of gethostname(3) and places the first 27 bytes after the new format number > > 129. This should give us a very low probability of collisions, assuming > > all machines have a unique name. > > what happens if there's a collision? i'm not sure it's safe to assume > unique names.
The engineid is used to load the engine context of the originator agent. For unacknowledged pdu's this means at least loading the remote users (unlike get requests the users, keys and engineid are from the originator). If there's a collision for trapv2 this means that if a user exists on both remote agents but with different keys one of them will fail. But if you want to enter a new user of a new system and you find that that engineid already exist it should be a pretty big red flag that there's a collision and the new system can explicitly set the engineid. Similar if you ever want to set up something like "this engineid can only send from this ip": If you see that a new systems engineid already has such restriction it means you have to manually set the engineid. For existing get requests we don't have any risk: For acknowledged PDUs (get*/set) the engineid will be discovered (RFC3414 Section 4). And people can't have any hefty restrictions in place as is, because previously it was randomly generated at startup, so no persistent engineid to check on. I don't see any big risks here. A minor risk would be that if a hostname ever changes traps won't be received anymore, since the engineid changes. But changing a hostname seems like something that doesn't happen very often and brings with it a lot more migration research. But considering the question if there was a better idea for generating a consistent engineid by jmatthew@ on the 1st without any feedback I went with this one. If you still feel like there's a risk here after my previous reasoning feel free to come up with an alternative. We still have time to change it, and even then we have the range 130-255 to implement new formats (although then we come back to the discussion about defaults without negotiation) > > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also > > supported as well as arbitrary formats in the range 128-255 for other > > private enterprise numbers in hex format. > > > > OK jmatthew@ > > >
