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

From: "David Harrington" <[email-masked]>
Date: Mon, 5 Feb 2007 23:49:14 -0500

Hi,

Working on the -06- revision. Comments inline.

dbh

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 6:50 PM
> To: [email-masked]
> Subject: [Isms] review of draft-ietf-isms-tmsm-05
> 
> 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.

>From the abstract:
"This document describes a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work is
being done to expand the transport to include secure transport such as
SSH and TLS, using a subsystem will enable consistent design and
modularity of such Transport Models."

>From section 3.2.1:
"The RFC3411 architecture includes a Security Subsystem for enabling
different methods of providing security services, a Message Processing
Subsystem permitting different message versions to be handled by a
single engine, Applications(s) to support different types of
application processors, and an Access Control Subsystem for allowing
multiple approaches to access control. The RFC3411 architecture does
not include a subsystem for Transport Models, despite the fact there
are multiple transport mappings already defined for SNMP. This
document addresses the need for a Transport Subsystem compatible with
the RFC3411 architecture. As work is being done to expand the
transport to include secure transport such as SSH and TLS, using a
subsystem will enable consistent design and modularity of such
Transport Models."

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

I went through and looked at each "defines" and "describes", and tried
to make sure I was consistent. 
The architecture extension is defined.
The ASIs and changes to existing ASIs are defined.
The cache, which is implementation-specific, is described.
There is an open question of whether we need to "define" the cache (or
at least the parts of the cache that contain the model-independent
parameters).
The LCD is described, since that is implementation-specific.

I looked at the "discuss" terminology in the document, and I changed
soe to describe, but most instances really are about having transport
models discuss certain aspects that will have system-wide impact, but
the details of which are model-specific.

> 
> 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?

Fixed.

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

Moved this to the introduction.
> 
> 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.

Modified the text. Suggested text welcome.
> 
> 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".

Done.
> 
> pg. 8: missing space
> 
>    The RFC3411 architecture,and the USM assume that a 
> security model is
>                             ^
Done

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

Modified the preamble to describe what is new.
> 
> 
> 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?

No. meant the lists.

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

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

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

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

Each of these sections has only one requirement - 1) there must be a
mapping to model-independent securityname, securitylevel, and
securityModel, 2) authentication and uathorization must remain
separated, and 3) the model-independent parameters must be passed
through the ASIs. I don't think there is anything to gather into a
table.
> 
> 
> 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.

There are only three security parameters, and they affect all ASIs.

> 
> 
>    This document describes a cache mechanism, into which the
transport
>    model puts information about the transport and security
parameters
> Describes or defines?

Describes. The definition of the cache is implementation-specific.

> A section number reference would be good here.
Done.

> 
> 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/

Done.

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

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

These aspects depend on the specific transports, and cannot be defined
here. They can be discussed here to ensure they are defined in the
specific models.

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

I think you are looking for a neat little bulleted list, but most of
the requirments need to be described in context. I don't know that I
could extract unambiguous bullet items into a neat little list.

If you want to provided sugggested text, I would welcome that.

> 
> 
> 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?

There was WG consensus to permit transport-session reuse, including
for different types of messages (request/response vs notification),
and the reuse decision is made by the transport-specific model.
Because of this, an application does not know whether it is the first
to request a session with these security parameters (including
direction), and if it is not the first, whether the session was
initially opened as a request/response session or as a notification
session.

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

No, the application does not necessarily know if it is establishing a
session; the session is a transport-specific mechanism. The session
might already exist, started by a different application, and might be
reused for this message. The application might specify a session it
has used before (using domain/address/name/model/level), but the
session might have been closed for various reasons, so this message
might cause the establishment of a new session.

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

The whole idea of session reuse has never been used with SNMP before,
or any other widely-deployed IETF NM protocol (if there were any), and
I don't know that we understand how session reuse will be impacted by
different security protocols, or how session reuse will impact certain
security protocols, or what the impact to SNMP interoperability will
be. I don't think we have enough understanding of the impacts of
discarding a message sent through a reused session to define what the
normative behavior should be for all transport models at this point. 

> 
> 
> 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?

Sessions are a transport-specific mechanism, controlled at the
transport-model-specific level. 
> 
>    The decision to tear down a session is implementation-dependent.
> 
> Why?
> Why isn't session control requirements part of the standard?

Because this is an architecture document, and transport session
mechanisms (and controls) are transport-protocol specific.

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

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

It doesn't much; the diagram is from RFC34111. The Transport Subsystem
defines ASIs to replace "Send SNMP xxx Message to the network" and
"Receive SNMP xxxx Message from the Network". I included text to make
this point clearer. It would be difficult to make this point clear by
extending this diagram to include a transport subsystem and to show
the flows, and especially any session. There just isn't enough room in
69 columns of ASCII art.

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

This whole section is about providing that context.

> 
> 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?

It's from RFC3411.

> 
>    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?

It may be appropriate to not discard such messages; a security
protocol may provide a resumme capability that maintains adaequate
assurances that the session security properties are identiical and
that it is safe to "reopen" a session on demand and use that to send
the Response message. That would be transport-model specific. For
protocols that cannot provide such assurances, discarding the Response
message may be the most appropriate solution.

> 
> 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.     
Fixed.                                    ^^^^^^^
> 
> 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?

This text was taken directly from RFC3411; since this is an extension
to RFC3411, there is an assumption the reader has read RFC3411. I
added an explcit statement that the reader is expected to havee read
RFC3411 first.

I modified this text to make it clearer that this was text taken from
RFC3411.

> 
> 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?

This ASI did not exist in RFC3411. It is defined here.

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

Model-specific is used in RFC3411. It is used throughout this document
to describe a parameter, like securityName, that is independent of any
model, whether transport, message-processing, security or access
control models.

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

The following paragraphs described the semantics, but I realize they
went beyond the transport subsystem a bit too far, so I rewrote these
sections.

> 
> 6.3.3.  Processing an Incoming Message
> 
> Should explain how the ASI semantics change due to the new
parameter.

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

Fixed.

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

Improved description of this appendix and its purpose.
> 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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