Subject: [Isms] Transport directorate review of Last Call: draft-ietf-isms-tmsm

From: Allison Mankin <[email-masked]>
Date: Wed, 15 Apr 2009 23:57:54 -0700

Transport directorate review of Last Call: draft-ietf-isms-tmsm 
Transport Subsystem for the Simple Network Management Protocol (SNMP)

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC [email-masked] if you reply to or forward
this review.

Overall, this document gets a thumbs-up from me.  And for extra measure
I read over  draft-ietf-isms-transport-security-model-12.txt to
understqnd its context and found the two very well meshed.  I found
both of them a very strong base to the in-progress document
draft-ietf-isms-secshell-15.txt.  

A top-level comment/question has to do with the draft's use of the
TDomain/TAddress textual convention from RFC 2579, instead of RFC 3419.
The revision notes call this out as mid-course choice and I'm sure the
working group and the MIB experts have good reasons for it.  But 
is a transport running on, say, TCP-IPv6 going to be appropriate
with RFC 2579?  In any event, it would be good since this is a
transport-focused document if you could add a NOTE about the
design choice of TDomain/TAddress.

Here's what I'm reading in RFC 3419:
   Transport endpoints which carry SNMP traffic SHOULD continue to use
   the definitions from the SNMPv2-TM MIB module where applicable.  They
   SHOULD use the transport domain values defined in this memo for SNMP
   transports not defined in the SNMPv2-TM MIB module, such as SNMP over
   UDP over IPv6.  Programs that interpret transport domain values
   should in addition accept all the transport domain values defined in
   this memo in order to provide interoperability in cases where it is
   not possible or desirable to distinguish the protocols running over a
   transport endpoint.

Section 2

Though I'm reviewing for the tsv-dir, I can't resist both
complimenting and fussing a bit about the paragraph in Section 2 about
the individual who considers three approaches to security and ends up
hiring a company that can handle all his or her needs comprehensively:

   The individual therefore
   achieves the desired security, with no significant effort on his part
   other than identifying requirements and verifying the quality of
   service being provided.

The discussion is very clear.  But "with no significant effort...other
than identifying requirements" is like the "small matter of programming."

Section 3.2.1

At the mention of multiple transport mappings for SNMP, please give
a reference.

Section 3.2.1.3

   A secure Transport Model will establish an authenticated and possibly
   encrypted tunnel between the Transport Models of two SNMP engines.
   After a transport layer tunnel is established, then SNMP messages can
   be sent through the tunnel from one SNMP engine to the other.
   Transport Models MAY support sending multiple SNMP messages through
   the same tunnel.

Is the MAY sentence at the end of paragraph necessary?  From the
standpoint of a transport person, it's hard to envision that an
implementor would establish security and tear it down per message,
but this MAY is saying that's the default.  Later you advise
implementations against this.

3.3.1.  No SNMP Sessions

   The transportDomain and transportAddress identify the transport
   connection to a remote network node.  Elements of the transport
   address (such as the port number) might be used by an application to
   send a particular PDU type to a particular transport address.

This paragraph describes a heuristic to get around the fact that
"the transport subsystem does not have access to the pduType."
What do pduTypes include?  What's a useful example of this hint
that makes this reversal worth including? 

Readability of the two paragraphs before:
   The Transport Subsystem may support transport sessions.  However, the
   transport subsystem does not have access to the pduType, so cannot
   select a given transport session for particular types of traffic.

   Certain parameters of these ASIs might be used to guide the selection
   of an appropriate transport session to use for a given request by an
   application.
To what does "these ASIs" refer?  This hint isn't very clear either.
Transport readers want to know...

3.3.4

   If a secure transport session is closed between the time a request
   message is received, and the corresponding response message is sent,
   then the response message SHOULD be discarded, even if a new session
   has been established.  The SNMPv3 WG decided that this should be a
   SHOULD architecturally, and it is a security-model-specific decision
   whether to REQUIRE this.

In other words, under USM, the late response MAY be accepted.
This text says that under TSM the security model could decide to 
accept late responses.  The cases are very different from each
other and I think there should be a warning that this MAY
could be complex to get right.

TYPO:
Commander Generator -> Command Generator

7.1 Coexistence, Security Parameters, and Access Control

This section points out that enabling security models prior
to transport-based security will have the result of bypassing
the secure transport.  Therefore, it recommends against
trying coexistence and recommends that the secure transport
model detect that the tmStateReference cache is not populated
due to use of these other models and fail.  However, the
section also states that the previous User-Based Security
Model differs from the transport-based security model in 
that it was designed not to depend on external network
services.  The draft talks about "provisioning" USM AuthPriv
for use when TSM is too stressed to work:

   It is RECOMMENDED that operators
   provision authPriv USM to supplement any security model or transport
   model that has external dependencies, so that secure SNMP
   communications can continue when the external network service is not
   available.

Please make this clearer.  This isn't a coexistent USM, right?
It's a failback that is enabled when access to dependencies is
not possible or when there's other stress determined.

6. IANA Considerations

For completeness and for some Security Models as yet
unknown, you might want to add a registration for
TCP to the SNMP Transport Domain:

tcp snmpTCPDomain 

The reference would be this RFC once published.