Re: [Syslog] [TLS] Missing dead peer detection in DTLS

[Erick O <[e-mail]>]

________________________________
From: tom.petch <[e-mail]>
To: Gerhard Muenz <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: Michael Tuexen <[e-mail]>; Daniel Mentz <[e-mail]>
Sent: Thursday, July 30, 2009 2:44:11 AM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS

Gerhard

Thank you for pointing this out; it had escaped me.

What I had thought though was that the lack of flow control with DTLS over UDP
is a problem, and that the lack of this with syslog over UDP led the syslog RFC
[RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as might be
expected, syslog over UDP.

This in turn led me to expect that syslog over DTLS over UDP would not be
acceptable to the IESG, rather that syslog over DTLS over SCTP would become the
RECOMMENDED transport.

So; several thoughts.

This is an update to the extensions RFC, RFC4366, which itself is being updated
by the TLS working group (hence my addition of them to the list) and I would
much rather have one extensions RFC rather than several.  This is a good concept
and fills a need; perhaps the TLS working group would take this on.

Flow control remains an issue which I do not think that this extension
addresses.

Is this a security exposure? or just, like syslog over UDP, an inconvenient
truth?

The petch-gerhards draft allows the recipient of the unidirectional flow to
initiate the DTLS 'connection', and so enables it to re-establish the connection
when anything goes wrong.  This would seem an alternative to consider.

Tom Petch

----- Original Message -----
From: "Gerhard Muenz" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: "Michael Tuexen" <[e-mail]>; "Robin Seggelmann"
<[e-mail]>; "Daniel Mentz" <[e-mail]>
Sent: Tuesday, July 28, 2009 10:41 AM
Subject: [Syslog] Missing dead peer detection in DTLS


Hi,

This mail goes to the ipfix and syslog mailing lists in order to
summarize the common issues regarding DTLS.

IPFIX specifies support of DTLS as mandatory for transport over UDP and
SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for
transport over UDP.

In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and we
will have a first implementation of IPFIX-over-DTLS/SCTP very soon.
During this implementation effort, we found that the current
specification of DTLS/UDP has a severe flaw when used with
unidirectional protocols (like IPFIX): The sender cannot recognize if
the receiver has crashed and lost the DTLS state.

We discuss this issue in a draft:
http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00
http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf

I've had a look at draft-feng-syslog-transport-dtls-01 and
draft-petch-gerhards-syslog-transport-dtls-02. It seems that this
problem has not yet been covered, although the problem should be the
same for SYSLOG.

As a solution, the DTLS Heartbeat Extension has been proposed very recently:
http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00
A feature patch for OpenSSL is available:
http://sctp.fh-muenster.de/dtls-patches.html#features

So, I think that we should support this standardization initiative as it
solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can
specify that the DTLS Heartbeat Extension MUST be implemented.

Dan suggested to have a single document solving the DTLS issues
regarding unidirectional protocols. I think that such a document is not
needed if we have DTLS Heartbeat Extension.

Regards,
Gerhard

Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  [phone]      Fax: [phone]
E-mail: [e-mail]    WWW: http://www.net.in.tum.de/~muenz



_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls