On 2021/08/09 22:35, Martijn van Duren wrote: > 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: mart...@cvs.openbsd.org 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@ > > > > > > >
Thanks. I haven't looked closely at this before, I just know that it's common for agents to set it randomly at startup (net-snmp docs say "must be consistent through time and should not change or conflict with another agent's engineID. Ever." which isn't exactly clear which is the stronger requirement - consistency or not conflicting). Regarding the commit, the manual doesn't mention that there's a default. Should it? e.g. maybe Index: snmpd.conf.5 =================================================================== RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.54 diff -u -p -r1.54 snmpd.conf.5 --- snmpd.conf.5 9 Aug 2021 19:13:08 -0000 1.54 +++ snmpd.conf.5 9 Aug 2021 20:57:10 -0000 @@ -153,6 +153,7 @@ generation for the .Ar auth and .Ar key . +By default, a hash of the system hostname is used. .Ar enterprise specifies the private enterprise number of the instance and can be either an integer or .
