On Mon, 2021-08-09 at 21:58 +0100, Stuart Henderson wrote: > 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).
I'd say the not changing. Because it determines how a password is changed to an auth-/priv-key, which is needed to decipher an incoming unacknowledged trap. However, users will always find some legitimate reason to change it. But that should be their burden. If during setup it's found that a conflict occurs it should be fine to change the engineid, but if you change it in production authentication might fail. > > Regarding the commit, the manual doesn't mention that there's a default. > Should it? e.g. maybe Manpages: not my strong suit :-) I've documented it under hosthash: "This format is the default" Maybe it should be more clear. Does this read better (including some extra explanation for your prior questions)? 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 22:16:18 -0000 @@ -158,6 +158,12 @@ specifies the private enterprise number integer or .Ic openbsd .Pq default . +The engineid should not change after taken into production and should be unique +within an administrative domain. +If +.Ic engineid +is not specified it defaults to +.Ic engineid hosthash . .Pp .Ar format can be one of the following: @@ -194,7 +200,6 @@ If used for the local engineID, then .Ar hostname defaults to the value of .Xr hostname 1 . -This format is the default. .It Ar number Ar octetstring The engineID's format identifier is set to .Ar number
