Subject: [Isms] review of draft-ietf-isms-tmsm-05

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jan 2007 15:37:25 -0800

Hi,

I was asked to review the transport subsystem draft.
I hope these comments help.

Andy

Review of draft-ietf-isms-tmsm-05

Abstract

This section is a bit redundant and vague.
It is not very clear why a transport sub-system is needed,
and is being added now, so many years after SNMP Arch was done.

I know SNMP doesn't like to confine any system components,
so there is "an" architecture instead of "the" architecture,
but IMO, this document needs to be more normative, and more clear
about what is being defined (normative) vs. discussed (informational).

2.  Motivation

The home security analogy is not very clear.
Consider introducing this section with a sentence that securing a
network protocol is like securing a home or business, and make it clear
that this intro relates to the following paragraphs in this section.

   This document describes a Transport Subsystem extension to the
   RFC3411 architecture.

Which approach (of the 3 choices) does this document take?

The diagram on pg. 5 should be introduced and quickly explained where
this document fits into the diagram.

pg. 6:

   SNMP continues to work without any surprises.

Expand or add an example of the kind of surprise that this
document addresses.  I assume you mean non-transparent
inter-operability with an SNMP peer by "no surprises".
That should be explained here.

pg 7:

   Transport models MUST be able to coexist with other transport models,
   and may be designed to utilize either TCP or UDP or SCTP.

The section leading up to this last sentence is really good,
but SCTP is not mentioned at all, and then this summary sentence
suggests supporting it.  In the first sentence, suggest changing
"other transport models" to "each other".

pg. 8: missing space

   The RFC3411 architecture,and the USM assume that a security model is
                            ^
pg. 9 diagram:

Can you highlight what is new vs. already in place for SNMP?
There is a caption that says (traditional SNMP agent) but
this is not clear, since it shows new transports TCP, SSH, and TLS.
It is an excellent diagram, but could be explained a bit more.

Sec 3.2.1 General:  It is not clear what is existing and what
is new in these procedures.

3.2.1.1.  USM and the RFC3411 Architecture

   The following diagrams illustrate the difference in the security

Do you mean previous diagram, since this is on pg. 10?

3.2.2.  Access Control Requirements

General:  Would help to have an executive summary at the
start of this section (like a table) that lists what new
things the 3.2.2.* sections are going to explain.

3.2.2.1.  securityName Binding
   processing model via the processIncoming() ASI.  This translation
                      should remove parens ^^

   If the type of authentication provided by the transport layer (e.g.
                   (several places)                missing comma      ^

pg 12:

   A transport model must not specify how the securityModel and
   securityName could be dynamically mapped to an access control
   mechanism, such as a VACM-style groupName.  The mapping of
   (securityModel, securityName) to a groupName is a VACM-specific
   mechanism for naming an access control policy, and for tying the
   named policy to the addressing capabilities of the data modeling
   language (e.g.  SMIv2 [RFC2578]), the operations supported, and other
   factors.  Providing a binding outside the Access Control subsystem
   might create dependencies that could make it harder to develop
   alternate models of access control, such as one built on UNIX groups
   or Windows domains.  The preferred approach is to pass the model-
   independent security parameters via the isAccessAllowed() ASI, and
   perform the mapping from the model-independent security parameters to
   an authorization-model-dependent access policy within the access
   control model.

   To provide support for protocols which simultaneously send
   information for authentication and authorization, such as RADIUS
   [RFC2865], model-specific authorization information MAY be cached or
   otherwise made available to the access control subsystem, e.g., via a
   MIB table similar to the vacmSecurityToGroupTable, so the access
   control subsystem can create an appropriate binding between the
   model-independent securityModel and securityName and a model-specific
   access control policy.  This may be highly undesirable, however, if
   it creates a dependency between a transport model or a security model
   and an access control model, just as it is undesirable for a
   transport model to create a dependency between an SNMP message
   version and the security provided by a transport model.

A summary table gathering all the requirements from large paragraphs
(like the 2 above) would be helpful.

3.2.3.  Security Parameter Passing Requirements

A table summarizing the security parameters would be helpful.
It would be useful to refer back to the diagram as to
the specific information flow or ASI in question.

   This document describes a cache mechanism, into which the transport
   model puts information about the transport and security parameters

Describes or defines?
A section number reference would be good here.

3.3.  Session Requirements

   Some secure transports may have a notion of sessions, while other
   secure transports might provide channels or other session-like thing.

s/thing/mechanism/

   Throughout this document, the term session is used in a broad sense
   to cover sessions, channels, and session-like things.  Session refers

s/things/mechanisms/

   It is important to note that the architecture described in [RFC3411]
   does not include a session selector in the Abstract Service
   Interfaces, and neither is that done for the transport subsystem, so
   an SNMP application cannot select the session except by passing a
   unique combination of transport type, transport address,
   securityName, securityModel, and securityLevel.

This seems like a very important paragraph (and requirement).
It would be nice to explain why all these parameters are needed
to identify a session.

   All transport models should discuss the impact of sessions on SNMP
   usage, including how to establish/open a transport session (i.e., how
   it maps to the concepts of session-like things of the underlying
   protocol), how to behave when a session cannot be established, how to
   close a session properly, how to behave when a session is closed
   improperly, the session security properties, session establishment
   overhead, and session maintenance overhead.

   To reduce redundancy, this document will discuss aspects that are
   expected to be common to all transport model sessions.

IMO, 'define' (not 'discuss') should be used when referring to standards
track documents.

A summary (somewhere in the doc) of all the requirements
this spec defines + another summary of the requirements
that are expected to be defined externally.

3.3.1.  Session Establishment Requirements

   SNMP Applications typically have no knowledge of whether the session
   that will be used to carry commands was initially established as a
   notification session, or a request-response session, and SHOULD NOT
   make any assumptions based on knowing the direction of the session.

Is this true?  Why doesn't the session initiator know what type
of session is being requested?

   If an administrator or transport model designer wants to
   differentiate a session established for different purposes, such as a
   notification session versus a request-response session, the
   application can use different securityNames or transport addresses
   (e.g., port 161 vs. port 162) for different purposes.

Is this a normative definition?
Maybe a use case and example diagram would be helpful.

   An SNMP engine containing an application that initiates
   communication, e.g., a Command Generator or Notification Originator,
   MUST be able to attempt to establish a session for delivery if a
   session does not yet exist.  If a session cannot be established then
   the message is discarded.

Does the application know it is establishing a session?
Are the sessions just a transport layer mechanism?
Some explanation of the document I should have read before
starting this document should be in the Introduction section.

   If a session can be reused for a different type of message, but a
   receiver is not prepared to accept different message types over the
   same session, then the message MAY be dropped by the receiver.  This
   may strongly affect the usefulness of session reuse, and transport
   models should define a standard behavior for this circumstance.

IMO, this document should define the behavior, and not pass it
to the transport implementation.  Silently dropping messages
in a purposely undefined way is not good standards practice.

3.3.2.  Session Maintenance Requirements

   A transport model can tear down sessions as needed.  It may be
   necessary for some implementations to tear down sessions as the
   result of resource constraints, for example.

I am unclear on the session model here wrt/ which components
are aware of sessions.  Does the application initiate session
control or not?  I usually think of sessions as user-controlled
and user-configured inactivity timeout.  Is that what is
meant by resource constraints?

   The decision to tear down a session is implementation-dependent.

Why?
Why isn't session control requirements part of the standard?

3.3.3.  Message security versus session security

   ...
   SNMPv3 was designed to support multiple levels of security,
   selectable on a per-message basis by an SNMP application, because
   there is not much value in using encryption for a Commander Generator
   to poll for non-sensitive performance data on thousands of interfaces
   every ten minutes; the encryption may add significant overhead to
   processing of the messages.

Should note that this non-sensitive polling is an example,
not imply this is the only reason for per-message security.

4.1.  Command Generator or Notification Originator

   This diagram from RFC3411 4.6.1 shows how a Command Generator or
   Notification Originator application [RFC3413] requests that a PDU be
   sent, and how the response is returned (asynchronously) to that
   application.

I don't see how the diagrams in sec 4. relate to sessions
and to the transport sub-system.

5.  Cached Information and References

   This document differentiates the tmStateReference from the
   securityStateReference. 

Suggest providing some context as to what these variables are,
and how they are different.

5.1.  securityStateReference

   A Message Processing Model has the responsibility for explicitly
   releasing the cached data if such data is no longer needed.  To
   enable this, an abstract securityStateReference data element is
   passed from the Security Model to the Message Processing Model.  The
   cached security data may be implicitly released via the generation of
   a response, or explicitly released by using the stateRelease
   primitive, as described in RFC3411 section 4.5.1."

Is securityStateReference a new construct or something from RFC 3411?

   The information saved should include the model-independent parameters
   (transportDomain, transportAddress, securityName, securityModel, and
   securityLevel), related security parameters, and other information

   needed to imatch the response with the request.  The Message
sp.          ^^^^^^

   If the transport model connection is closed between the time a
   Request is received and a Response message is being prepared, then
   the Response message MAY be discarded.

What other options would be appropriate?

5.2.  tmStateReference

   For each message or transport session, information about the message
   security is stored in a cache, which may inlcude model- and
sp.                                         ^^^^^^^

6.  Abstract Service Interfaces

   An error indication may return an OID and value for an incremented
   counter and a value for securityLevel, and values for contextEngineID
   and contextName for the counter, and the securityStateReference if
   the information is available at the point where the error is
   detected.

Which error indication? Response to what operation?

6.2.  Processing for an Outgoing Message

   The sendMessage ASI is used to pass a message from the Dispatcher to
   the appropriate transport model for sending.

   statusInformation =
   sendMessage(
   IN   destTransportDomain           -- transport domain to be used
   IN   destTransportAddress          -- transport address to be used
   IN   outgoingMessage               -- the message to send
   IN   outgoingMessageLength         -- its length
   IN   tmStateReference              -- reference to transport state
    )

Are there any changes to this ASI?
What is the purpose of this section?

6.3.  Processing an Incoming SNMP Message

6.3.1.  Processing an Incoming Message

   If one does not exist, the Transport Model will need to create an
   entry in a Local Configuration Datastore referenced by
   tmStateReference.  This information will include transportDomain,
   transportAddress, the securityModel, the securityLevel, and the
   securityName, plus any model or mechanism-specific details.  How this
   information is determined is model-specific.

Model-specific?
This is kind of a new term.
Implementation-specific has been raised so far, but not this.

6.3.2.  Prepare Data Elements from Incoming Messages

   The abstract service primitive from the Dispatcher to a Message
   Processing Model for a received message is:

   ....
   Note that tmStateReference has been added to this ASI.

Should explain how the ASI semantics change due to the new parameter.

6.3.3.  Processing an Incoming Message

Should explain how the ASI semantics change due to the new parameter.

7.  Security Considerations

   secret keys does not result in disclosure of past session keys.  The
   editors recommend that each proposed transport model include a
   discussion in its security considerations of whether perfect forward
   security is appropriate for the transport model.

The editors recommend does not sound very official.

   Since the cache and LCD will contain security-related parameters,
   they should be kept in protected storage.

What exactly is meant by protected?

   [I-D.ietf-netconf-ssh]  Wasserman, M. and T. Goddard, "Using the
                           NETCONF Configuration Protocol over Secure
                           Shell (SSH)", draft-ietf-netconf-ssh-06 (work
                           in progress), March 2006.

Update reference to RFC 4742.

Appendix A.  Parameter Table

   Following is a CSV formatted matrix useful for tracking data flows
   into and out of the dispatcher, transport, message, and security
   subsystems.  Import this into your favorite spreadsheet or other CSV
   compatible application.  You will need to remove lines feeds from the
   second, third, and fourth lines, which needed to be wrapped to fit
   into RFC limits.

A.1.  ParameterList.csv

Not clear what this section is for.
The syntax is very cryptic.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms