Subject: [Isms] Comments on the TSM document

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Aug 2008 15:38:57 -0700

First, let me preface this with an important point: the document is very
well written.  It's been a while since I last read it and the current
version is very nicely polished.  Thanks for doing such a good job
David!  It's worth noting again that I reviewed it in the context of the
DTLS draft I've been working on and see no issues (aside from the ones
I'll mention) with using multiple transports underneath it (like SSH
and DTLS both).

I do have a few minor things to point out though with edit text, and a
maybe few questions which I'll bring up in separate messages.

* Section 2.1.1, 3rd paragraph:        

   - The current text says:

     "The Transport Security Model is called a Security Model to be
     compatible with the RFC3411 architecture.  However, this Security
     Model does not provide security mechanisms such as authentication and
     encryption itself, so it SHOULD always be used with a Transport Model
     that provides appropriate security."

   - I disagree with this general statement (and this paragraph isn't as
     negative as the one in the security consideration sections which
     has an extra sentence).  The TSM does not perform any encryption or
     authentication or integrity protection services, but it is very
     much a security model and it does provide a few critical security
     functions.

   - How about this instead (and this needs to be replace Section 8,
     paragraph 3 (in the Security Considerations) too):
   
     "The Transport Security Model is a Security Model that is compatible
     with the RFC3411 architecture.  However, this Security Model does
     not provide some of the typical security mechanisms such as
     integrity protection, authentication and encryption itself since it
     relies on the lower level transport to perform these tasks.  The
     Transport Security Model does, however, provide critical security
     related tasks (such as dropping requests that fail to meet
     securityLevel requirements or requests that came in over transports
     not authorized by configuration settings).  The Transport
     Security Model SHOULD always be used with a Transport Model that
     provides appropriate security."

* Section 2.3, 3rd paragraph:

  - drop the **s or change to ()s
    - (was this an editing note? it's not standard ID mark-up).

* Section 2.3, last paragraph:

  - Add ", configure the Transport Security Model to manipulate
    securityName mappings, and a scalar to control securityName mapping
    prefix processing".
    - (that last bit does assume consensus in the other email thread has
      been reached).

* General MIB: snmpTsmLCDTable:
  - Was there a result to the discussion about the naming of this table?
    - LCD is kind of generic
    - Personally, I'd suggest "snmpTsmConnectionTable" or something.
      - (I refrained from using "session")

* Sections 4 and 5:
  - These are EOPs and if we want to be consistent with the other
    documents, I'd suggest having a separate EOP top-level section and
    putting all the EOP steps within this document into the new
    top-level EOP section.  This is obviously a nit though.

* Section 4.2, Step 5:
  - nit: Step 5 could be improved by describing how the message parts
    should be combined with a better verb?  How about "The wholeMsg is
    now created by serializing the message parts together."

    - (this more closely resembles the USM wording...  really the only
      verb I changed was "combine" to "serialize")

* Section 5.2:
  - Step 5:  
    - Delete the "," after "(Priv)," to avoid grouping confusion.
  - Step 6:
    - "the security data is cached..."
    - I'd suggest listing what security data you're talking about.  It's
      probably important to get right and I'm not even sure, without
      analyzing it in detail, which ones should be cached.

* Section 6:
  - Add "and a scalar to configure securityName mapping prefix
    processing" if consensus is reached on the new scalar.

* Section 6.4 to 6.5:
  - New section needed for the potential scalar

    <section title="The snmpTsmConfig Subtree">
    <t>This subtree contains a scalar that specifies whether the TSM
    should remove (the default) or leave the transport specific prefix
    string that is attached to tmSecurityNames.</t>
    </section>

* Section 6.4 (current before insertion of just discussed new section):

  - Should the VACM mib be added here?  I'd think so.

* MIB:
  - nit: indentation is funky after "snmpTsmMIBObjects" definition
  - nit: descriptions oddly indented/outdented: snmpTsmLCDDomainTable,
    snmpTsmLCDDomainEntry,
  - issue: snmpTsmLCDDomainTable vs snmpTsmLCDTransformEntry

* Section 8.1:
  - First 'o' bullet:
    - change "valid domains" to "transport models" since I think most
      people aren't used to the "domain" terminology.
  - third 'o' bullet:
    - Add "Access to the" to the beginning
    - Add "objects" before "may"

* Section 9:
  - I'd like to answer the "DISCUSS" comment by saying:  I don't think
    this is the right document to discuss default ports.  The TSM
    doesn't have a clue what the requirements of the transports are
    below it and thus this isn't the right document to discuss anything
    related to the transport itself.  It'd be something that would need
    to be considered on a per-transport basis.

* Appendix A:
  - I'm not sure :162 is a good choice for a transport address to use
    for an example snmpSSHDomain address.  :22 would probably be a
    better choice (or an IANA assigned different port altogether).
    Certainly, however, 162 is not a good choice :-)
  - For the snmpTargetParamsTable row, the snmpTargetParamsSecurityModel
    should be "YY" (with a note to the editor) not the text string
    TransportSecurityModel.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms