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 tsv-dir(_at_)ietf(_dot_)org 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf