Re: [Isms] IsmsQuestions on TLSTM/TSM and RFC 5343

[Frank Fock <[e-mail]>]

Hi David,

I personally I have not encountered the
"unique engine ID" issue yet. However,
I get complains from users of SNMP4J
and SNMP++ APIs for several month (if not
years now) who encounter problems if their
network if they try to get values from
more than one device with SNMPv3.

After analysis of dumps and log files,
there are two common errors made by the
manufacturer of the devices (or admins):

1. Using a non-unique hardcoded or unchanged
default value for all deployed devices.
2. The device does not increase its engineBoots
counter when restarted.

The second one is a common error for years
now, whereas the first one got more "popular"
within the last few months.

Both issues above seem to be caused by some
(popular?) SNMP command generator software
out there, that does resynchronize engine ID
and time without asking the user/application
layer. Otherwise this problem would have been
detected by the admins/device creators before
the error had been deployed to the field.

As a consequence of the above problems, I am
asked from time to time to provide also
auto-resynchronization of engine ID and time,
which I refuse, of course.
But asking for such changes in an API shows
how low the security awareness is.
To "get it working" seems the primary driver
:-(

I do not know which companies are creating
the buggy devices or running the incorrect
administered networks, but I could collect
that information starting from now.

Best regards,
Frank

On 24.01.2011 16:46, David Harrington wrote:
> Hi,
>
> I am a bit surprised that a couple companies are producing
> non-compliant devices, and we haven't heard anything on our lists
> asking about the uniqueness requirement until now.
> Frank, have you contacted the companies' technical support to ask
> about this non-compliance?
>
> IIRC,
> snmpEngineID is supposed to be administratively assignable (e.g., via
> config file).
>
>                   The initial value for this object may be configured
>                   via an operator console entry or via an algorithmic
>                   function.  In the latter case, the following
>                   example algorithm is recommended.
>
> The vendor might provide a default, but it is up to the deployer to
> make sure the value is set to a unique value within the domain.
> If what Frank is seeing is a non-changeable value in a device, I think
> the implementation is non-compliant.
> If what Frank is seeing is duplicate IDs within a deployment, the
> admin is preumably at fault for not properly setting the initial
> values to be unique.
>
> dbh
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of t.petch
>> Sent: Monday, January 24, 2011 9:12 AM
>> To: Frank Fock; Wes Hardaker
>> Cc: [e-mail]
>> Subject: Re: [Isms] IsmsQuestions on TLSTM/TSM and RFC 5343
>>
>> ----- Original Message -----
>> From: "Frank Fock"<[e-mail]>
>> To: "Wes Hardaker"<[e-mail]>
>> Cc:<[e-mail]>
>> Sent: Sunday, January 23, 2011 6:24 PM
>>
>>> Hi Wes,
>>>
>>> Thanks for your reply (and also those of Tom
>>> and Juergen).
>>>
>>> I understand that RFC 5343 solves the
>>> contextEngineID discovery problem, but
>>> within the last 10 years with SNMPv3
>>> I learned, that most SNMPv3 users do not
>>> understand the authoritative and context engine
>>> ID concepts.
>>>
>>> There are also a couple of companies
>>> creating SNMPv3 devices with identical
>>> authoritative engine ID for all instances
>>> of their device. We API developers are then
>>> asked to work around these problems :-(
>>
>> That surprises me (and sounds like a potential disaster).
>>
>> To quote RFC3411
>> " Within an administrative domain, an snmpEngineID is the unique and
>>     unambiguous identifier of an SNMP engine.  Since there is a
> one-to-
>>     one association between SNMP engines and SNMP entities, it also
>>     uniquely and unambiguously identifies the SNMP entity within that
>>     administrative domain.  Note that it is possible for SNMP
>> entities in
>>     different administrative domains to have the same value for
>>     snmpEngineID.  Federation of administrative domains may
> necessitate
>>     assignment of new values."
>>
>> which seems clear, unless the concept of an engine is unclear.
>>
>> On the other hand, it is much easier to burn the same identifier
> into
>> everything, rather than using a MAC address type approach and
>> make each device unique. Perhaps we ask too much of those making
>> devices.
>>
>> Tom Petch
>>
>>>
>>> That's why I thought about simplifying
>>> the SNMPv3 and making the discovery of
>>> a contextEngineID unnecessary if not
>>> required by the command generator.
>>>
>>> Nevertheless, I agree that using a single
>>> magic contextEngineID for the local context,
>>> would interfere with proxy applications,
>>> for example.
>>>
>>> I will now first finish my implementation
>>> and then make a complete report and analysis
>>> of the result. This will also include using
>>> contextEngineId discovery with USM.
>>>
>>> Best regards,
>>> Frank
>>>
>>>
>>> _______________________________________________
>>> Isms mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/isms
>> _______________________________________________
>> Isms mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/isms
>>
>

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