Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm

From: Alexey Melnikov <[email-masked]>
Date: Sat, 2 May 2009 15:10:54 +0200

Discuss:
In general this is a well written document and I hope to clear this DISCUSS very soon.

3.2.1.  Architectural Modularity Requirements

 [...]

   To encourage a basic level of interoperability, any Transport Model
   SHOULD define one mandatory-to-implement security mechanism, but
   should also be able to support additional existing and new
   mechanisms.

Why this SHOULD is not a MUST? I am expecting a mandatory-to-implement to be a MUST.

3.2.2.1.  securityName and securityLevel Mapping

 [...]

   Documents defining a new transport domain MUST define a prefix that
   MAY be prepended by the Security Model to all passed securityNames.

I might be slightly confused here: passed by whom?

   The prefix MUST include from one to four ASCII characters, not

You probably didn't mean any US-ASCII character here, e.g. I don't think
you wanted to allow control characters, spaces, etc.
Wouldn't it be better if this is defined as US-ASCII alpha-numeric?

   including a ":" (ASCII 0x3a) character.  If a prefix is used, a
   securityName is constructed by concatenating the prefix and a ":"
   (ASCII 0x3a) character followed by a non-empty identity in an
   snmpAdminString compatible format.  Transport domains and their
   corresponding prefixes are coordinated via the IANA registry "SNMP
   Transport Domains".

3.3.4.  Message security versus session security

   Some Transport Models might support only specific authentication and
   encryption services, such as requiring all messages to be carried
   using both authentication and encryption, regardless of the security
   level requested by an SNMP application.  A Transport Model MAY
   upgrade the security level requested by a transport-aware security
   model, i.e. noAuthNoPriv and authNoPriv might be sent over an
   authenticated and encrypted session.  A Transport Model MUST NOT
   downgrade the security level requested by a transport-aware security
   model, and SHOULD discard any message where this would occur.

What is an alternative to discarding?
(I.e. why the last SHOULD is not a MUST)

Comment:
I think the document is a bit lax with SHOULDs, some of which might be better specified as MUSTs or just removed. For example:

3.3.3.  Session Maintenance Requirements

 [...]

   If a Transport Model defines MIB module objects to maintain session
   state information, then the Transport Model MUST define what SHOULD
   happen to the objects when a related session is torn down, since this
   will impact interoperability of the MIB module.

Maybe just say "MUST define what heppens to the objects ..."?

3.3.4.  Message security versus session security

 [...]

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

Enclose some SHOULDs in "" to emphasize that they are not declaring requirements?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 2 May 2009 15:15:37 +0200

>   corresponding prefixes are coordinated via the IANA registry "SNMP
Also, I think the document is a bit unclear on how these prefixes are 
used. Can you provide an example?

Thank you,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: "David Harrington" <[email-masked]>
Date: Tue, 5 May 2009 18:04:47 -0400

Hi Alexey,

Thanks for the review.
I am updating my sources as needed.
comments inline.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alexey Melnikov
> Sent: Saturday, May 02, 2009 9:11 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm
> 
> Discuss:

remember these are transport models, not security models. Some
transport models can be non-secure. 

What if we defined a new transport model using SCTP or 10GE, for
example? We can use that with User-based Security Model, which does
its own security work. Why would it be required that the SCTP or 10GE
Transport Models define a mandatory-to-implement security mechanism?
(and with RFC3411, it would be wrong to specify that USM is the
mandatory-to-implement security mechanism for a specific transport
model).

We also allow non-standard proprietary transport models and on the 
architectural level having a non-standard transport model without a 
mandatory-to-implement security mechanism is just fine. 

We use SHOULD to provide guidance to model developers, without
assuming we can predict what is approrpiate for all future transport
models.

> I might be slightly confused here: passed by whom?

Is this wording clearer?
prepended to all securityNames passed by the Security Model.

> Wouldn't it be better if this is defined as US-ASCII alpha-numeric?

We can change this to US-ASCII alpha-numeric.

> (I.e. why the last SHOULD is not a MUST)

RFC3411 has a modular architecture, and we try not to constrain the
specific behavior of yet-to-be-defined models and implementations with
MUSTs. We use SHOULD to provide guidance rather than a hard rule.

It is expensive to generate messages only to discard them during the
final steps of processing (sending them). In the Transport Subsystem,
the SNMP message is fully formed before handing it to the Transport
Model, and if transport-security is used, then the message contents
should be independent of the transport used. A new Transport Model
could, for example, be defined that returns the fully-formed message
to the requesting application, which might then choose to send it
using a different security model or different security association or
a different address (in a multi-homed receiver) that can meet the
securityLevel requirement. If we mandate in the architecture that it
MUST be discarded, then we do not permit such solutions.

> 
> Comment:
> I think the document is a bit lax with SHOULDs, some of which 
> might be better specified as MUSTs or just removed. For example:
> 

done.

We use a different convention:
>From section 1.2:

   Non uppercased versions of the keywords should be read as in normal
   English.  They will usually, but not always, be used in a context
   relating to compatibility with the RFC3411 architecture or the
   subsystem defined here, but which might have no impact on
on-the-wire
   compatibility.  These terms are used as guidance for designers of
   proposed IETF models to make the designs compatible with RFC3411
   subsystems and Abstract Service Interfaces (ASIs) (see section
3.2).
   Implementers are free to implement differently.  Some usages of
these
   lowercase terms are simply normal English usage.

I'll certainly double-check al usages, but generally we used
uppercased keywords when we thought it would impact interoperability,
and lowercase where we thought it would impact modularity or
inter-model expectations within an SNMP entity.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 May 2009 20:38:49 -0400

> assuming we can predict what is approrpiate for all future transport

In this case I think maybe we should eliminate the text Alexey quoted 
entirely.  As you point out, the architecture is modular; IMHO this means 
that under normal circumstances a transport model should _not_ be 
specifying a mandatory-to-implement or even a RECOMMENDED security model; 
that is up to SNMPv3 or some application, not each transport model.

The interesting exception is secure transport models designed to be used 
with TSM.  These models should RECOMMEND if not REQUIRE support for TSM, 
since they are fairly useless without it (you can use SSH with USM, but you 
don't really get more or different security than you would using TCP with 
USM).

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Tue, 5 May 2009 22:40:36 -0400

A Transport Model cannot require a specific security model. That would
violate the RFC3411 modularity. The WG discussed this at length.

dbh

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Tuesday, May 05, 2009 8:39 PM
> To: David Harrington; 'Alexey Melnikov'; [email-masked]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-tmsm
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 May 2009 22:54:37 -0400

> violate the RFC3411 modularity. The WG discussed this at length.

No.  A transport model cannot work with only one security model; _that_ 
would violate modularity.  A transport model specification certainly can 
require that implementations also implement a particular security model, 
particularly when not doing so would both be silly and result in poor 
interoperability.  I see no modularity problem in saying "if you implement 
SSHTM, you must also implement TSM".

-- Jeff

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 5 May 2009 23:15:02 -0400

David Harrington writes...

> A Transport Model cannot require a specific security model. That
> would violate the RFC3411 modularity.

Well, yes it would.  OTOH, the RFC3411 architecture never envisioned that
the actual security function of any security model would be "outsourced" to
a transport model.  In order to work correctly, the SSHTM and the TSM are
wedded.  You could devise another secure transport model that would work
with TSM, but you cannot effectively (securely) use TSM with a non-secure
transport model, nor use SSHTM with secure-transport-unaware security model,
such as USM.

That was the architectural tradeoff the WG was forced to accept in order to
be able to support security at the transport layer rather than security
integral to the SMNP protocol as the RFC3411 architecture assumes.

There is some mix-and-match obtainable, but there is not complete
independence.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 May 2009 16:15:45 -0400

Hi,

Done

dbh

> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Wednesday, May 06, 2009 11:19 AM
> To: David Harrington
> Cc: [email-masked]; [email-masked]
> Subject: My DISCUSSes on draft-ietf-isms-* documents
> 
> David,
> I am directing this message to you, as you were the most 
> active person 
> discussing my DISCUSSes and comments. You can co-ordinate with your 
> co-editors.
> 
> Considering the amount of small changes to the documents, I 
> would like 
> to suggest that you post an updated version of your drafts before 
> tomorrows IESG telechat, so that I can either clear or at 
> least shorten 
> my DISCUSSes.
> 
> Thanks,
> Alexey
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 May 2009 11:09:20 +0100

>Hi Alexey,
Hi David,
My replies are inline.

>assuming we can predict what is approrpiate for all future transport
I think I will watch the conclusion of this discussion on the mailing 
list - so far I see several people disagreeing with you.

>prepended to all securityNames passed by the Security Model.
I think it is.

>We can change this to US-ASCII alpha-numeric.
Good.

>MUST be discarded, then we do not permit such solutions.
I think you are talking about implementation details which might not 
match every implementation.
Anyway, I think adding a couple of sentence saying what you said above 
would make the context for the SHOULD much clearer.

 [...]

>We use a different convention:
I was thinking about:

  The SNMPv3 WG decided that this should be a "SHOULD" architecturally, ...

But never mind, this is only a comment.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 07 May 2009 11:24:07 +0100

Thank you for addressing my concerns. I cleared my DISCUSSes.