Subject: [Isms] IETF Last Call summary for tmsm/tsm/secshell

From: <[email-masked]>
Date: Thu, 16 Apr 2009 11:08:22 +0200

The IETF Last Call for tmsm/tsm/secshell ended yesterday (the radius
draft is coming a bit later). According to my notes, we got the
following comments:

1) Juergen commented MIB module names and copyright statements
http://www.ietf.org/mail-archive/web/isms/current/msg03477.html

The MIB module names could be handled with RFC Editor notes.
I've entered the following ones (please yell if there's something
wrong or if you strongly object):

   secshell: Replace all occurrences of "SSHTM-MIB" with
   "SNMP-SSH-TM-MIB" (also in the MIB module in Section 7)

   tsm: Replace all occurrences of "SNMP-TSM-MIB" with
   "SNMP-TRANSPORT-SM-MIB" (also in the MIB module in Section 7)

The MIBs already have a copyright notice. The IESG and IETF Trust are
currently discussing whether every MIB also needs to include the full
BSD licensing terms, or just a pointer to the licensing terms (like
MIBs so far have done). I would propose we let the RFC Editor fix this
text once a decision has been reached (should happen soon -- the
trustees are having a face-to-face meeting this week).

2) IANA reviews:

https://datatracker.ietf.org/idtracker/draft-ietf-isms-tmsm/comment/93834/
https://datatracker.ietf.org/idtracker/draft-ietf-isms-transport-security-model/comment/93958/
https://datatracker.ietf.org/idtracker/draft-ietf-isms-secshell/comment/93833/

There was some discussion on what the "keywords" for the TCP port
numbers should be. 

http://www.ietf.org/mail-archive/web/isms/current/msg03486.html
http://www.ietf.org/mail-archive/web/isms/current/msg03487.html
http://www.ietf.org/mail-archive/web/isms/current/msg03488.html
http://www.ietf.org/mail-archive/web/isms/current/msg03489.html

The conclusion seemed to be that "snmpssh"/"snmpssh-trap" are probably
clearer than "snmps"/"snmps-trap" (proposed by IANA) or
"sshtm"/"sshtm-trap" (not obvious it's related to snmp).  I've entered
the following RFC Editor note (please yell if there's something wrong
or if you strongly object):

   Section 10:
   OLD:
   1.  two TCP registered port numbers in the
       http://www.iana.org/assignments/port-numbers registry which will
       be the default ports for SNMP over an SSH Transport Model (SSHTM)
       as defined in this document, and SNMP over an SSH Transport Model
       for notifications (SSHTM-TRAP) as defined in this document.  It
       would be good if the assigned numbers were x161 and x162.
   NEW:
   1.  two TCP registered port numbers in the
       http://www.iana.org/assignments/port-numbers registry which will
       be the default ports for SNMP over an SSH Transport Model (snmpssh)
       as defined in this document, and SNMP over an SSH Transport Model
       for notifications (snmpssh-trap) as defined in this document.  It
       would be good if the assigned numbers were x161 (snmpssh) and x162
       (snmpssh-trap).

3) Vijay Gurbani's Gen-ART review for tmsm:
http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html

One nit about white space/indentation -- will get fixed by
the RFC editor when they assign the RFC numbers.

4) Ben Campbell's Gen-ART review for tsm:
http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html

Couple of editorial comments, all extremely minor. I'd suggest 
handling these during RFC Editor stage.

5) Allison Mankin's transport directorate review for tmsm:
http://www.ietf.org/mail-archive/web/isms/current/msg03490.html

At least a reply reply is needed, and possibly some small
clarifications. It's possible these could be handled by RFC Editor
notes.

David, can you reply and propose text?

I hope we can get the RFC Editor notes to address Allison's comments
soon, so I've placed these on the agenda of next Thursday's IESG
telechat (April 23). If we don't have text by Monday,
I'll move them to the next telechat (May 7th).

Best regards,
Pasi

---

From: "David Harrington" <[email-masked]>
Date: Thu, 16 Apr 2009 11:29:27 -0400

Hi Pasi,

At ietf74, I mentioned some editorial changes that I think should be
done, but never posted them during IETF Last Call. The biggest change
I recall is the separation of the discussion of notification access
control from the discussion of proxy (which does no access control). I
think that is a bigger change than an RFC Editor note can handle.

I think some of Allison's comments point out places where our text is
not clear enough yet, and much of this has to do with the
architectural constraints. I do not think these could be handled well
by an RFC Editor note.

I suggest the best approach is for me to make the following requested
changes to the documents, keeping the changes as small as possible,
and let the WG review the changes. An additional benefit of doing this
ourselves is that I would have the updated sources for the documents.

I haven't thoroughly reviewed all the changes needed for Allison's
comments, but I think the whole thing should take no more than two
days editing (and composing). I can also send direct responses to the
reviewer comments as part of that process.

Does that sound OK?

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 5:08 AM
> To: [email-masked]; [email-masked]
> Subject: IETF Last Call summary for tmsm/tsm/secshell
>

---

From: <[email-masked]>
Date: Thu, 16 Apr 2009 19:48:19 +0200

OK -- I've moved these to the May 7th IESG telechat
(which means updated drafts are needed by end of April).
 
Best regards,
Pasi

> From: ext David Harrington [mailto:[email-masked]]
> Sent: 16 April, 2009 18:29
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: IETF Last Call summary for tmsm/tsm/secshell
> 
> Hi Pasi,
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2009 20:21:50 +0200

> (which means updated drafts are needed by end of April).

Let me add that it would be very good to have updated drafts by the
end of next week so we all have time to review the changes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 17 Apr 2009 10:48:13 -0400

Hi,

1) In rev08, we changed all instances of SNMP-TRANSPORT-SM-MIB to
SNMP-TSM-MIB to be consistent with the naming guidelines in RFC4181.
See the change log. I propose to not make this change back and forth
over and over.
So, I guess this is a -1. ;-)

I will add an RFC editor note to make sure the MIB copyright follows
trust guidelines. The existing document contains the updated MIB
copyright required by the Trust at time of publication (just prior to
ietf74).

2) I have contacted IANA with our requested changes

3, 4, 5) will review comments, edit, and respond

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Apr 2009 00:37:54 -0400

Last Call: draft-ietf-isms-tmsm and
draft-ietf-isms-transport-security-model
Transport Subsystem for the Simple Network Management Protocol (SNMP)

1) Juergen commented MIB module names

RFC4181 recommenda a naming convention where the module name, module
identity, and prefixes are consistent: 

 - The module name should be of the form XXX-MIB (or XXX-TC-MIB for a
     module with TCs only), where XXX is a unique prefix (usually all
     caps with hyphens for separators) that is not used by any
existing
     module.  For example, the module for managing optical interfaces
     [RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB.

   - The descriptor associated with the MODULE-IDENTITY invocation
     should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx
is
     a mixed-case version of XXX starting with a lowercase letter and
     without any hyphens.  For example, the OPT-IF-MIB uses the prefix
     optIf, and the descriptor associated with its MODULE-IDENTITY
     invocation is optIfMibModule.

   - Other descriptors within the MIB module should start with the
same
     prefix xxx.  OPT-IF-MIB uses the prefix optIf for all
descriptors.

I don't think we should change SNMP-TSM-MIB to SNMP-TRANSPORT-SM-MIB.
I don't see significant benefit in this change.

I do not object to changing SSHTM-MIB to SNMP-SSHTM-MIB or
SNMPSSH-MIB.

> the RFC editor when they assign the RFC numbers.

I believe this is related to the version of xml2rfc in use. It seems
to vary after xml2rfc upgrades. When the RFC Editor does their final
pass, it should be fine.

> handling these during RFC Editor stage.

The "*" is part of the official name of the SNMPv2 variation.

reference to USM provided.

section 4.2 first two paragraphs ARE an ordered sequence - note that
3) follows a ways down in the procedures.

pointer to smi-registry provided for mib-2 

removed open issues and change log sections

added pointer to secshell document for port assignment

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

NEW:
This document uses TDomain textual conventions for the SNMP-internal
MIB modules defined here for compatibility with the RFC3413 MIB
modules and the RFC3411 Abstract Service Interfaces.

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

reference for transport mappings added

OLD:
   Transport Models MAY support sending multiple SNMP messages through
   the same tunnel.
NEW:
            While the Community Security Models and the User-based
Security Model establish a security association for each SNMP message,
newer Transport Models MAY support sending multiple SNMP messages
through the same tunnel to amortize the costs of establishing a
security association.

> 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? 
NEW:
... the transport subsystem does not have access to the pduType (i.e.,
the SNMP operation type) ...
NEW:
For example, the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB are used to
   configure notification originators with the destination port to
which
   SNMPv2-Trap PDUs or Inform PDUs should be sent, but the transport
subsystem never looks inside the PDU.

OLD: 
The SNMPv3 WG decided that this should be a SHOULD architecturally,
and it is a security-model-specific decision whether to REQUIRE this. 
NEW:
The SNMPv3 WG decided that this should be a SHOULD architecturally,
and it is a security-model-specific decision whether to REQUIRE this.
The architecture does not mandate this requirement to allow for future
security models where this might make sense, but not requiring this
could lead to added complexity and security vulnerabilities, so most
security models SHOULD require this. 

Network stress discussion
NEW:
However, in times of network stress, a secure transport model may not
work
properly if its underlying security mechanisms (e.g., Network Time
Protocol (NTP) or Authentication, Authorization, and Accounting
(AAA) protocols or certificate authorities) are not reachable. The
User-based Security 
Model was explicitly designed to not depend upon external network 
services, and provides its own security services. It is RECOMMENDED 
that operators provision authPriv USM as a fallback mechanism 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.

snmpTCPDomain: I think such a domain should be registered when a model
is defined to use it.

---

From: <[email-masked]>
Date: Mon, 27 Apr 2009 09:36:34 +0200

Hi David,

Everything here looks good to me. Can you submit an updated
draft?

Best regards,
Pasi

> Sent: 23 April, 2009 07:38
> Cc: 'Allison Mankin'; [email-masked]; [email-masked]; vkg@alcatel-
> lucent.com; [email-masked]
> Subject: RE: IETF Last Call summary for tmsm/tsm/secshell #1, #3, #4,
> #5
>