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

[Wes Hardaker <[e-mail]>]

>>>>> On Sun, 16 Jan 2011 11:25:12 +0100, Frank Fock <[e-mail]> said:

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

Hi Frank!  I'm certainly glad to hear you're implementing the latest and
greatest of the SNMPv3 RFCs.

FF> While the implementation of TSM and TLSTM was
FF> straightforward

That's certainly good news!

FF> RFC 5343 imposed some architectural difficulties:

That's, of course, less than good news.  But I'm sure we can work
through the issues.

FF> 1. The contextEngineID discovery mechanism of
FF> RFC 5343 cannot be implemented within the SNMPv3
FF> message processing model (MPv3) because the
FF> MPs are not designed to be able to send messages
FF> themselves.

I don't think it actually says this should be the case anywhere in
5343.  It actually implies, in multiple places, that it's done more at
the application level of the SNMPv3 architecture.

Now, real-world library APIs, may wish to hide the discovery process
from the application developers to make it easier to implement an
application.  It's much easier to do this than make each application
handle discovery itself.

Now, having said that technically I think it's the application that
should initiate discovery, I'll also amend this viewpoint with "remember
that 3410 is *An* architecture.  I suspect many stacks may choose to
implement contextEngineID discovery somewhere within their MP or similar
architecture.  As long as the bits on the wire are good, you can do
anything you want.  The pitfall may come at a later date when a future
RFC defining a new architectural block makes you rewrite your
MP-discovery-mechanism because your hack wasn't technically
"block-compliant".  However, I doubt this is of a big concern to most
SNMPv3 stack vendors.

Net-SNMP implements it within the stack somewhere near the "MP" layer.
Since the Net-SNMP architecture pre-dates SNMPv3 by years and years, the
lines between the blocks are a bit fuzzy.

FF> Unfortunately, RFC 5343 requires that the
FF> USM discovery has precedence over RFC 5343
FF> contextEngineID discovery.

Now here's an important missing component of your analysis:  Previously
*no* RFC described how to do contextEngineID discovery.  The *only*
discovery mechanism was defined for USM and it was to discover the
*securityEngineID*.  There is no where that says you should magically
copy the securityEngineID to the contextEngineID if you don't have a
better one to use.  That's just what everyone did because it made sense!
But please do correct me if I'm wrong here (I didn't go back and re-read
every line in the SNMPv3+USM specs to double check; I do know that the
one sentence in RFC3414 that includes "contextEngineID" certainly
doesn't say this).

Rather than make every security module magically do contextEngineID
discovery too, 5343 makes it generic such that security modules that
don't need an engineID at all (like TSM) don't need to create a
discovery mechanism for a value they don't need to make use of.  TSM
doesn't have, or need, a notion of a securityEngineID so the choices
were:

1) make all the engines that wanted to send a DTLS packet first send a
   USM packet to do engineID discovery and continue to use the magic
   "securityEngineID to contextEngineID copying routine".
2) define a new, more generic, contextEngineID discovery mechanism which
   is more securityEngineID agnostic.

The tack taken was #2 which resulted in RFC5343.  In fact, there is
nothing wrong with:

  + application needs to send a SNMPv3/USM message
  + USM does discovery for it's securityEngineID
  + application does it's contextEngineID discovery
  + using both values, sends the resulting mesasge

That should work just fine, and technically might be the right way to do
it considering prior to 5343 there was no notion of a contextEngineID
discovery method.  It's taken for granted by previous implementations
that you could copy the value out of the securityEngineID field or the
contextEngineID field.

FF> 2. The reasoning for the contextEngineID
FF> discovery is not clear to me.

Hopefully the above explains the historical context of why it's needed.

FF> If the TSM would replace the defined magic local engine ID
FF> ’8000000006’H (put in the scopedPDU by the sender) by the local
FF> engine ID of the SNMP entity receiving the scopedPDU before handing
FF> it over to the Dispatcher, then discovery would not be needed and
FF> the effect would be the same, wouldn't it?

I do suspect that there are other ways in which discovery could be done,
including using the above suggestion.  But it'd require that every
defined security model follow this suggestion or some other similar
suggestion.  5343 leaves it a bit more architecturally separated, which
in my opinion is architecturally cleaner.  Plus, I'm not sure the above
is legal either:

   The procedure when a command generator receives a message is as
   follows:

   (1) If the received values of messageProcessingModel, securityModel,
       securityName, contextEngineID, contextName, and pduVersion are
       not all equal to the values used in the original request, the
       response is discarded.

So technically, if a CG sends a response with a 8000000006 value and
gets back a different engineID value it must discard the response.  The
RFC5343 method actually returns with the same special contextEngineID
value (8000000006) but the payload contains the correct value.

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

(Note: 5.2.1 == 5.2 bullet #1)

It should mean the local SNMP entity processing the request.

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

I think I've done that because the CG would drop the response with a
different contextEngineID.  (though some might argue that you could let
every agent out there appear to be "8000000006" according to the CG, I
don't think this is how the contextEngineID was perceived to act).

-- 
Wes Hardaker
Cobham Analytic Solutions