[SNMP4J] Multiple SNMPv3 trap senders

Frank Fock fock at agentpp.com
Fri Oct 27 23:03:28 CEST 2006


Adam,

Please find my comments inline below:

Adam Brons wrote:
> 
> Here's a bit more background as to what I'm trying to do.  We have an 
> existing product that received SNMP Trap and INFORM messages.  The product 

OK, we can stop here:
For traps, the sender is authoritative. That is, each sender may use
its own password for the same user name, because each sender MUST
have a different engine ID (that's a plain SNMPv3 requirement).

For informs, the receiver is authoritative. That is, there is only
a single user name / password combination defined by the receiver.
All senders must use this combination to successfully send an inform
to that receiver. Each sender discovers the receiver's engine ID
by engine ID discovery.

> requires that the user predefine the v3 username, password, password 
> encryption, privay encryption, and privay passphrase for each sending SNMP 
> agent.  It does not require the user to enter the authoritative engine ID 
> though.  This product uses SNMP++ and I see that the USM::add_usm_user 
> does not require an engine ID. 

That's because SNMP++ only supported global users in earlier
versions. But as pointed out above, this was not an restriction
for your use case.
> 
> I've been tasked with converting this application to Java and I've choosen 
> SNMP4J as the SNMP library.  What I'm kinda boggled over is how the 
> product would have ever worked properly if it does note require the engine 
> ID.  According the the RFC's and my poking around in the SNMP4J source I 

It could work, see above.

> see that the UsmUserTable indexes (assuming unique constraint) the table 
> by (engine ID + UsmUserName).  So if the user defined two SNMP agents 
> using the same UsmUserName and assuming that engine ID == "" wouldn't this 
> cause a problem if the authentication protocol, privacy protocol, and 
> associated passphrases are different?

When both engine IDs are equal, then SNMPv3 communication will not work
properly anyway.
> 
> What I'm proposing with the conversion to Java is that we start requiring 
> that the engine ID be defined as part of the SNMP agent definition. 
>
This is a good idea in any case.

Best regards,
Frank

> Thanks for any help in advance, 
> 
> Adam Brons
> TSOM Software Engineer
> IBM Tivoli Software
> 
> 
> 
> 
> Frank Fock <fock at agentpp.com> 
> 10/26/06 07:23 PM
> 
> To
> Adam Brons/Atlanta/IBM at IBMUS
> cc
> snmp4j at agentpp.org
> Subject
> Re: [SNMP4J] Multiple SNMPv3 trap senders
> 
> 
> 
> 
> 
> 
> Hi Adam,
> 
> with SNMP4J you can use localized USM users and non localized
> USM users. When using localized USM users, the user name is
> bound to a specific engine ID and therefore it the user name
> must not be globally unique.
> 
> Also note, that the trap sender is the authoritative entity.
> 
> For more information on these concepts, please refer to the
> SNMPv3 RFCs.
> 
> Best regards,
> Frank
> 
> Adam Brons wrote:
>> I'm currently developing a SNMP Manager of sorts.  Where people can 
>> configure the manager to listen for SNMPv3 trap messages from several 
>> sources.  Each of these sources will most likely be a separate 
> workstation 
>> and may have separate IT staff managing it.  I've read through the 
> javadoc 
>> for USM UsmUser and so forth and am wondering what what should be done 
> if 
>> two sources supplie the same username?  I'm assuming the UsmUserTable is 
> 
>> basically a hashmap or sorts so I have to have unique users names.  I've 
> 
>> toyed with the idea of using EngineID in combination with the username, 
>> but I was wondering if there's something else I could use.
>>
>> Another quesiton was how to require a certain level of authenticaiton 
> and 
>> privacy protocol? If I wanted to drop a SNMP trap because it has a 
> lesser 
>> authentiation protocol, would this be done via the 
>> CommandResponder.processPDU() method?
>>
>> I am providing links to mailing list archives which I found to be 
> similar 
>> in nature.
>>   http://lists.agentpp.org/pipermail/snmp4j/2005-July/000587.html
>>   http://lists.agentpp.org/pipermail/snmp4j/2005-June/000545.html
>>
>> Thanks - in advance.
>>
>> Adam Brons
>> TSOM Software Engineer
>> IBM Tivoli Software
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> http://lists.agentpp.org/mailman/listinfo/snmp4j
> 

-- 
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com




More information about the SNMP4J mailing list