Community discussions

MikroTik App
 
TedRule
just joined
Topic Author
Posts: 15
Joined: Tue Nov 03, 2020 4:41 pm

SNMPv3 EngineID Probing efficiency

Fri Sep 17, 2021 5:14 pm

Some slightly surprising findings from delving into the inner workings of SNMPv3 recently.

When an SNMPv3 Session is setup, an initial EngineID probe is put out with no security, i.e. secLevel = noAuthNoPriv.

A MikroTik responds to this with a message which contains a valid EngineID, but apparently setting EngineBoots/EngineTime == 0

When the Session is first used and a GET/GETBULK is sent, the client uses EngineBoots/EngineTime == 0 because it knows
no better, but this message is sent with secLevel = authPriv, the MikroTik refuses to accept the request because
of a mismatching EngineBoots/EngineTime, and returns a usmStatsNotInTimeWindows REPORT containing the true EngineBoots/EngineTime,
which forces a retry of the GET/GETBULK.

The GET/GETBULK retry contains the true EngineBoots/EngineTime as cached from the previous authoritative response, and succeeds.

By contrast, Cisco Switches appear to respond to the initial EngineID probe with a VALID EngineBoots/EngineTime such that
the GET/GETBULK is sent with valid EngineBoots/EngineTime and no usmStatsNotInTimeWindows REPORT and retry is required.

It's also apparent that every SNMPv3 Session setup requires the initial EngineID probe, even if the retry for valid EngineBoots/EngineTime is not required.

A reading of the code for net-snmp on Linux indicates that the mapping of EngineID to EngineBoots/EngineTime appears to be held in a memory cache per-process,
so if the SNMP Session is shared by multiple requests within the same process, only the first Probe or GET is needed to cache the EngineID to EngineBoots/EngineTime mapping.

MikroTik's initial empty EngineBoots/EngineTime response may be thought reasonable as it is responding to an unauthenticated request, but if it returned nonsense,
the initial authenticated GET/GETBULK would simply suffer a usmStatsNotInTimeWindows REPORT provoked retry, and the local EngineBoots/EngineTime cache entry would eventually be corrected.

Consequently, there may be wasted effort on the part of both the SNMPv3 Client and Agent in getting the EngineBoots/EngineTime settings cached.

Can RouterOS be enhanced to report valid EngineBoots/EngineTime during the initial unauthenticated EngineID probe?

Who is online

Users browsing this forum: almdandi, baragoon, Bing [Bot], GoogleOther [Bot], loloski, pajapatak and 74 guests