Re: [Syslog] Missing dead peer detection in DTLS

Hi Tom,

a question in-line.

Best regards
Michael

On Jul 30, 2009, at 11:44 AM, tom.petch wrote:

> 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.
So I think it is actually congestion control what you are looking
for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right?
>
> 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.
This would mean, that
* SYSLOG/TLS/TCP/IP
* SYSLOG/DTLS/SCTP/IP
* SYSLOG/DTLS/DCCP/IP
are in principle acceptable, whereas
* SYSLOG/DTLS/UDP/IP
is not.
You would (from the congestion control perspective) have the same
classification when taking out the DTLS or TLS layer, right?
>
> 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" <[email protected]>
> To: <[email protected]>; <[email protected]>
> Cc: "Michael Tuexen" <[email protected]>; "Robin Seggelmann"
> <[email protected]>; "Daniel Mentz" <[email protected]>
> 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:  +49 89 289-18008       Fax: +49 89 289-18033
> E-mail: [email protected]    WWW: http://www.net.in.tum.de/~muenz
>
>
>
>