Subject: [Isms] FW: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 Apr 2010 14:44:37 +0200

I am not sure if this review made it to the ISMS WG mail list.
 
Dan

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
	Sent: Wednesday, April 07, 2010 6:41 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: [OPS-DIR] (Yet another) Review of
draft-ietf-isms-dtls-tm

	Background

	I had previously been asked to review this document for the
OPS-DIR as well as TSV-DIR.  At the time I sent my OPS-DIR review (prior
to IETF 77), I didn't find any major issues.  Then at IETF 77, I chaired
a discussion of DTLS-related transport issues for another protocol
(RADIUS over DTLS), and the question occurred to me that some of the
issues encountered there might also be relevant to SNMP over DTLS.  As a
result, I thought I would post some of those thoughts to both the
TSV-DIR and OPS-DIR.  In general, it occurs to me that the issues raised
in this (and other WGs) relating to use of DTLS transport might be
worthy of a document in their own right.  In practice, it might be
helpful for the IETF to provide some guidelines on how to use DTLS, much
as we provided guidelines for using IPsec.  

	Summary:

	   This document describes a Transport Model for the Simple
Network
	   Management Protocol (SNMP), that uses either the Transport
Layer
	   Security protocol or the Datagram Transport Layer Security
(DTLS)
	   protocol.  The TLS and DTLS protocols provide authentication
and
	   privacy services for SNMP applications.  This document
describes how
	   the TLS Transport Model (TLSTM) implements the needed
features of a
	   SNMP Transport Subsystem to make this protection possible in
an
	   interoperable way.

	General Observations

	Since the abstract claims that the document describes a
transport model for SNMP, I was expecting to find the kind of discussion
one normally expects in a transport model document, namely discussion of
transport issues.  In general, those kind of details are not present.
To some extent this is because transport issues are covered in two of
the normatively referenced documents, namely:

	   [RFC5590]  Harrington, D. and J. Schoenwaelder, "Transport
Subsystem
	              for the Simple Network Management Protocol
(SNMP)",
	              RFC 5590 <http://tools.ietf.org/html/rfc5590> ,
June 2009.
	 
	   [RFC5591]  Harrington, D. and W. Hardaker, "Transport
Security Model
	              for the Simple Network Management Protocol
(SNMP)",
	              RFC 5591 <http://tools.ietf.org/html/rfc5591> ,
June 2009.

	However, after looking through both of these documents, as well
as this one, I'm still missing some basic details that I have seen
discussed in other DTLS transport documents (such as RADIUS over DTLS).
One of these details concerns how a deployment transitions from
conventional UDP to DTLS.    There are a number of issues that come up
in a transition like this, such as whether DTLS and UDP are to be sent
on the same port, and if so, how that works.  In real deployments there
is typically no "flag day" so that (D)TLS and uprotected SNMP may
coexist for a while.  It can be onerous to have to track the upgrade
state of every device on the network, since they may not be uniform.  

	From the documents, it appears that the transition is expected
to be handled via the MIB and explicit management, but  I'd like to see
this issue discussed explicitly.  

	In the RADIUS over DTLS transport doc, the assumption was that
the RADIUS sever is upgraded to support DTLS first, and that the RADIUS
clients are upgraded over time, so that during the transition there can
be a mixture of DTLS and non-DTLS clients.  Once a client is upgraded to
support DTLS it is assumed to stay that way, so that the server can set
a "toggle" that the client has been upgraded, expecting that future
sessions from that client will be DTLS protected.  Eventually when all
the clients have been upgraded, a switch can be set on the server only
permitting DTLS sessions.  However, during the transition, it is not
assumed that there is a master list of all the clients that support
DTLS.  Rather, the server derives this list dynamically based on its
interaction with clients, and therefore can provide reports to the
administrator on the status of the transition.  The goal is to enable a
transition to DTLS operation which is relatively secure (e.g protecting
against downgrade attacks), while being easy to manage. 

	While Section 8.1 does talk about sessions and heartbeats, it
doesn't provide the details of how implementations are expected to
toggle between DTLS and unprotected SNMPv3.  For example, if DTLS and
regular SNMPv3 packets can be sent to the same port, how do
implementation distinguish DTLS packets from conventional SNMPv3
packets?  In some cases this can be done by looking at the initial
packet and deciding whether DTLS or uprotected SNMP is being used.  Once
that decision is made, then a toggle is set.  The toggle can be based on
the 5 tuple (source IP, dest IP, source port, dest port, UDP) or it
could be based on the source IP.  One the toggle is set for DTLS, only
DTLS packets will be accepted for that 5 tuple or IP address.   The
toggle might be kept in memory, or it might be saved to stable storage.

_______________________________________________
OPS-DIR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-dir

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Apr 2010 17:24:55 +0200

> I am not sure if this review made it to the ISMS WG mail list.

I think it did not - thanks for forwarding. Perhaps you can channel my
response back since I am not sure where to send it either since I am not
on the -dir lists myself...

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Subject: [OPS-DIR] (Yet another) Review of draft-ietf-isms-dtls-tm

[...]
 
> However, after looking through both of these documents, as well as
> this one, I?m still missing some basic details that I have seen
> discussed in other DTLS transport documents (such as RADIUS over
> DTLS).  One of these details concerns how a deployment transitions
> from conventional UDP to DTLS.  There are a number of issues that
> come up in a transition like this, such as whether DTLS and UDP are
> to be sent on the same port, and if so, how that works.  In real
> deployments there is typically no ?flag day? so that (D)TLS and
> uprotected SNMP may coexist for a while.  It can be onerous to have
> to track the upgrade state of every device on the network, since
> they may not be uniform.

SNMP transports in general co-exist and this is also true for DTLS and
UDP. The document requests a separate port for TLS/DTLS transports,
see the IANA consideration and the relevant *Domain definitions. Since
the document requires bidrectional authentication, a client needs a
proper certificate and thus some configuration effort is required to
enable DTLS and once a client is configured to use DTLS, we do not
assume it to fall back to an alternate transport.

> From the documents, it appears that the transition is expected to be
> handled via the MIB and explicit management, but I?d like to see

Since keys and certificates are requires, I can not see how such a
transition can ever work without explicit management.

> In the RADIUS over DTLS transport doc, the assumption was that the
> RADIUS sever is upgraded to support DTLS first, and that the RADIUS
> clients are upgraded over time, so that during the transition there
> can be a mixture of DTLS and non-DTLS clients.  Once a client is
> upgraded to support DTLS it is assumed to stay that way, so that the
> server can set a ?toggle? that the client has been upgraded,
> expecting that future sessions from that client will be DTLS
> protected.  Eventually when all the clients have been upgraded, a
> switch can be set on the server only permitting DTLS sessions.
> However, during the transition, it is not assumed that there is a
> master list of all the clients that support DTLS.  Rather, the
> server derives this list dynamically based on its interaction with
> clients, and therefore can provide reports to the administrator on
> the status of the transition.  The goal is to enable a transition to
> DTLS operation which is relatively secure (e.g protecting against
> downgrade attacks), while being easy to manage.

The SNMP world generally does not deal with such policy issues or more
specifically the existing SNMPv3 MIBs do not allow to express such
client specific state. In fact, in the SNMPv3 world, the identifier of
a client is its snmpEngineID and not its current transport endpoint.
And this perfectly makes sense in situations are IP addresses are not
assigned statically. To do what you suggest would require some major
surgery on SNMPv3 MIB modules the ISMS WG is not chartered to do.

> doesn?t provide the details of how implementations are expected to
> toggle between DTLS and unprotected SNMPv3.  For example, if DTLS
> and regular SNMPv3 packets can be sent to the same port, how do
> packet and deciding whether DTLS or uprotected SNMP is being used.
> Once that decision is made, then a toggle is set.  The toggle can be
> based on the 5 tuple (source IP, dest IP, source port, dest port,
> UDP) or it could be based on the source IP.  One the toggle is set
> for DTLS, only DTLS packets will be accepted for that 5 tuple or IP
> address.  The toggle might be kept in memory, or it might be saved
> to stable storage.

As mentioned above, both transports can co-exist and use different
port numbers and SNMP architecturally separates the identity of an
SNMP engine from its transport endpoint location.

/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: Wes Hardaker <[email-masked]>
Date: Mon, 12 Apr 2010 11:51:08 -0700

>>>>> On Mon, 12 Apr 2010 17:24:55 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> As mentioned above, both transports can co-exist and use different
JS> port numbers and SNMP architecturally separates the identity of an
JS> SNMP engine from its transport endpoint location.

I think one important thing to note is that the concerns discussed are
actually all handled by the existing transport configuration mechanisms
discussed in RFC3413 (a normative reference of this document).  IE, we
already have the ability to distinguish between who is talking to what
using what protocols and that configuration mechanism has been around
for a long time within the SNMP-TARGET-MIB and related MIB constructs.
Combined with the newly requested ports, that Juergen already mentioned,
this issue has already been discussed in the larger set of documents
that define how SNMPv3 works in the larger system.
-- 
Wes Hardaker
Cobham Analytic Solutions