Hi Tom,
understood. Thanks for the clarification.
Best regards
Michael
On Aug 2, 2009, at 11:11 AM, tom.petch wrote:
Reply inline, twice
Tom Petch
----- Original Message -----
From: "Michael Tuexen" <[email protected]>
To: "tom.petch" <[email protected]>
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>
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
