>>>>> On Wed, 2 Jun 2010 11:31:22 -0400, "Ron Rader" >>>>> <[email protected]> said:
RR> Now I wonder if we should take this back to the list... ? CCed again ;-) RR> What happens when Engine IDs collide? If I used systemName it is very RR> possible that they might. EngineIDs shouldn't collide. Ever. Multiple things happen with engineIDs: 1) The specs say engineIDs *MUST* be unique 2) managers store information based on the engineID about SNMPv3 boots/time values. If two agent's had identical engineIDs then the manager would get confused and would (likely) fail to talk with one of them. The problem with using IP addresses or system names or other things that may change after an engineID is created is that you have two choices: A) Don't change the engineID and keep using the old one even though it was derived from a different value. This is what most software (ours included) does (keep reading for why). It still creates conflicts though because when a new machine comes along at the new address or new name it suddenly creates the same engineID again. B) Change the engineID everytime the record you're deriving it from changes (IP address, system name, etc). But because user-keys are tied to the engineID so if you change the engineID you've just nuked your existing user database at the same time. So this functionally nukes the boxes accessibility on every move, which isn't any better. [unless you leave the master keys on the device for each user, but that defeats the whole purpose generally of localization in the first place]. So, the right thing to do is actually use a system that generates unique IDs, which is what the default Net-SNMP code does for this very reason. The downside is that the generated IDs must be copied-and-pasted when you absolutely need the engineID (like in the case of traps). EngineID discovery helps in most of those cases for user-simplification so you don't need to copy/paste engineIDs around. But this doesn't work for TRAPs and has security implications that aren't well documented (see my blog post at http://pontifications.hardakers.net/computers/limitations-of-snmpv3usm-when-combined-with-engineid-discovery/ . One of the reasons that I've been working for the last 2+ years on the SNMP over DTLS standard and then in the code base lately (along with others) is that much of these sorts of setup problems should be easier. (the downside is that it's UDP or TCP only, which I thought was a negative but the IETF wanted to reuse existing secure protocols). SNMP over DTLS still has engineIDs but they're discovered *after* the connection establishment and the security credentials aren't tied to it. Security boot strapping is always difficult, unfortunately, but with USM it's worse than it needs to be (IMHO). See if the instructions at: http://www.net-snmp.org/wiki/index.php/TUT:Using_TLS look better or worse than: http://www.net-snmp.org/wiki/index.php/TUT:SNMPv3_Options I think you'll find them better. And we're not done making them better yet either. I actually hope to drop more command line options from the required list so there are even less options to specify. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
