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

From: Michael Tuexen <[email-masked]>
Date: Thu, 30 Jul 2009 17:24:20 +0200

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-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: "Michael Tuexen" <[email-masked]>; "Robin Seggelmann"
> <[email-masked]>; "Daniel Mentz" <[email-masked]>
> 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-masked]    WWW: http://www.net.in.tum.de/~muenz
>
>
>
>

---

From: "tom.petch" <[email-masked]>
Date: Sun, 2 Aug 2009 11:11:03 +0200

Reply inline, twice

Tom Petch

----- Original Message -----
From: "Michael Tuexen" <[email-masked]>
To: "tom.petch" <[email-masked]>
Sent: Thursday, July 30, 2009 5:24 PM

a question in-line.

Michael

<tp>
For myself, no, I was not looking for or caring about congestion control, rather
security.

But when the syslog I-D got to the IESG, they did care about congestion, and so
the syslog I-D was modified to make syslog over TLS the RECOMMENDED transport,
not because it might or might not improve security but because it
offered congestion control, which UDP by itself does not.
</tp>

This would mean, that
* SYSLOG/TLS/TCP/IP
* SYSLOG/DTLS/SCTP/IP
* SYSLOG/DTLS/DCCP/IP

<tp>
I am unclear about your second sentence, but the first one, yes, I would expect
the first three to be acceptable to the IESG (which is rather important if you
want an I-D to become an RFC) and the last one not to be.  TLS (by using TCP),
SCTP, DCCP have acceptable congestion control, DTLS and UDP do not.

Tom Petch

> when anything goes wrong.  This would seem an alternative to consider.
<snip>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 5 Aug 2009 14:35:07 +0200

Hi Tom,

understood. Thanks for the clarification.

Best regards
Michael

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 11:27:28 +0200

[trimming Cc list to just syslog]

Tom Petch wrote:

> I am unclear about your second sentence, but the first one, yes, I
> would expect the first three to be acceptable to the IESG (which is
> rather important if you want an I-D to become an RFC) and the last
> one not to be.  TLS (by using TCP), SCTP, DCCP have acceptable
> congestion control, DTLS and UDP do not.

Well, syslog-over-UDP was acceptable to IESG, and was published as 
RFC 5426 couple of months ago.

Syslog-over-UDP is not the mandatory-to-implement or recommended
transport for in RFC 5424, due to both congestion control and
security reasons. Syslog-over-DTLS-over-UDP would have the
same challenges in congestion control, so probably it wouldn't
be the mandatory-to-implement or recommended transport either.
But that doesn't prevent it from being published as RFC.

Best regards,
Pasi

---

From: "tom.petch" <[email-masked]>
Date: Fri, 7 Aug 2009 14:40:29 +0200

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 07, 2009 11:27 AM

<tp>
Pasi

Thanks for that.  One trigger for this discussion was Chris's question,
as to whether we could write a syslog-over-DTLS I-D,
or whether it would be syslog-over-DTLS-over-UDP
or whether it would be syslog-over-DTLS-over-UDPandSCTP ....

Obviously an I-D covering more than one substrate could RECOMMEND
the one with flow control but, for myself, I would prefer just to cover a single
substrate, namely UDP (seeing that as the one most likely to be implemented).

So I see a difference from the syslog-over-UDP case in that there is
a close alternative to syslog-over-DTLS-over-UDP which does provide
flow control ie syslog-over-DTLS-over-SCTP (or DCCP), an alternative
that is much closer than in the choice of UDP versus TLS, so we might
be encouraged to include a substrate that did offer flow control.

Worst case scenario would be to produce a UDP only I-D and then get told
late in the day that we have to retrofit SCTP and/or DCCP in order to
address the concerns of the then Transport Area reviewers.  I appreciate that
it is impossible to predict the views of such reviewers in a year or two's time
but the reassurance I was looking for was that you thought that such an action
was unlikely.

Looking forward, I think that Chris's preference would be to have syslog over
DTLS with no reference to substrate. Mmmmmmm, I think that that would leave too
many issues uncovered, but I think that the question of substrate(s) is the
discussion we now need to have, with Joe's views, as potential editor, being of
particular interest to me.

Tom Petch
</tp>

Best regards,
Pasi