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

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

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?

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

<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

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