[Isms] Questions on TLSTM/TSM and RFC 5343

[Frank Fock <[e-mail]>]

Hi,

I am currently implementing RFC 5590, 5591 (TSM),
5953 (TLSTM), and 5343 (Context EngineID Discovery)
for SNMP4J 2.0 (snmp4j.org).

Next to the above, I also want to implement RFC 5592
(SSHTM).

I have not performed any interoperability tests with
other implementations yet, because my implementation
of the SNMP-TLS-TM-MIB is not ready. Within the
next two weeks, I will start interoperability
testing with the NET-SNMP implementation.

Nevertheless, I would like to give an early feedback
and to use the opportunity to ask some questions.

While the implementation of TSM and TLSTM was
straightforward, RFC 5343 imposed some
architectural difficulties:

1. The contextEngineID discovery mechanism of
RFC 5343 cannot be implemented within the SNMPv3
message processing model (MPv3) because the
MPs are not designed to be able to send messages
themselves.
The ASIs do not define a callback to the
Dispatcher for sending PDUs on behalf of the MPs.
Since timeout and retry values are also
not available for the MPs, sending discovery
PDUs has to be done by the Dispatcher.

The Dispatcher however, needs to know if
discovery is needed or not. In order to
be able to decide that, the Dispatcher needs
information of the used Security Model.
Unfortunately, RFC 5343 requires that the
USM discovery has precedence over RFC 5343
contextEngineID discovery. Whether USM
discovery is executed can be decided within
the MPv3/USM only, because the local engine
ID cache needs to be checked therefore.

It was unsatisfying to implement aspects
of the contextEngineID discovery in two
or three different components of the model.

I have not thought about a better solution
yet, but may be my second issue/question
would provide an alternative?

2. The reasoning for the contextEngineID
discovery is not clear to me. If the
TSM would replace the defined magic
local engine ID ’8000000006’H (put in
the scopedPDU by the sender) by the
local engine ID of the SNMP entity
receiving the scopedPDU before handing
it over to the Dispatcher, then discovery
would not be needed and the effect
would be the same, wouldn't it?

(The receiver would replace the local
engine ID in any responses of the TSM
with the magic local engine ID too.)

3. RFC 5591 §5.2.1 should be clarified.
Is the "local engine ID" the magic
engine ID ’8000000006’H or the engine
ID of the SNMP entity processing the
incoming message?

All in all, the RFCs seem to be implementable
as they are, however especially the discovery
mechanism increases the implementation complexity.
Implementations need to be able to send different
PDUs on behalf of a single application level PDU
and support REPORT processing for USM engine ID
and time discovery at the same time as "steeling"
regular RESPONSE PDUs from the incoming PDUs if
they are responses on contextEngineId discovery
requests.

May be someone on the list can explain to me,
why my suggestion (2) above, is not a feasible
replacement of the contextEngineId discovery?

The current (alpha) implementation of TLSTM
and TSM for SNMP4J can be downloaded from:

https://server.oosnmp.net/dist/snapshot/org/snmp4j/snmp4j/2.0-SNAPSHOT/
https://server.oosnmp.net/dist/snapshot/org/snmp4j/snmp4j-agent/2.0-SNAPSHOT/

Regards,
Frank Fock