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

["t.petch" <[e-mail]>]

<inline>

----- Original Message -----
From: "Frank Fock" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, January 16, 2011 11:25 AM

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?

<tp>
The MPP cannot send a message but does not need to.
The Dispatcher is called by the application, and so knows
the Security Model and whether or not the contextEngineID
is known, so the dispatcher knows all that it needs to
in order to know whether or not to invoke the
discovery.  I am unclear where the problem lies.
</tp>


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.)

<tp>
engineID uniquely identifies an engine in a domain, making
object values that would otherwise have the same identifiers
unique.  A Command Generator needs to know the
engineId of the Command Responder.  Originally,
 USM performed the discovery so no more was needed.
With TSM, and perhaps with others, the Security Model
does not perform discovery so another mechanism is
needed; hence RFC5343

I would expect the well-known local value that
all engines implementing this to have to only
be used for discovery, not for any other
PDU.
</tp>

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?

<tp>
Indeed it should, perhaps you should raise an
erratum.  RFC5591 existed as an I-D for many years before
RFC5343 so when the I-D was written, local engineID could only
mean the one that uniquely identified the local engine within
the domain.  RFC5343 introduced an ambiguity that those
of us reviewing RFC5591 did not pick up.

I am sure that many on this list will be very interested in
your further experience and especially in your interoperability
tests.

Tom Petch

</tp>

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