Hi Daniel,
comments in-line.
Best regards
Michael
On Jan 19, 2009, at 10:54 PM, Daniel Mentz wrote:
Thank you all for your answers.
I think I will go for the hack that misuses re-negotiation as a kind
of
heartbeat, keep alive or echo request. I tried to avoid this hack at
first because it is a computational burden. AFAIK re-negotiation means
restarting from scratch which means that expensive public key
operations
have to be performed.
@Michael: Using DTLS on top of SCTP is high on my TODO list. I would
be glad if you could help me with this. I'll get back to you with
more questions regarding this. I've heard that I'll need your
patches for OpenSSL and FreeBSD to make it work.
OK.
Btw, does OpenSSL support renegotiation when using DTLS? It failed
when I tried it with s_client and s_server. I learned from some
forum that there's a bug regarding an incorrect message sequence
number. Robin Seggelmann provided a patch which has not been merged
into the upstream version. Is this still the current status?
As far as I know yes. Robin has tested renegotiations with DTLS/UDP.
We have
a couple of patches for DTLS/UDP. However, they have not been
integrated.
The patches for DTLS/SCTP require the DTLS/UDP patches...
@Ger: I disagree with you on the fact that I'm trying to convert DTLS
into TCP. If I understand Nagendra's Paper correctly DTLS strives to
be
some kind of secure UDP.
Quote:
DTLS is explicitly designed to be as compatible as possible with
existing datagram communication systems,...
... This property allows applications to simply replace each
datagram socket with a secure datagram socket managed by DTLS.
.... DTLS semantics should mimic UDP semantics thus allowing DTLS
implementations to mimic the UDP API.
end quote
I do accept the fact that there might be a loss of datagrams. But
when I send out a packet I want to be sure that there's at least a
chance that it might reach the receiver. If the receiver crashes and
comes up again there's no chance that a packet might ever be
decrypted due to the lost state (pre-master secret etc.) in the
receiver process.
Also, IKE (IPSec) is somewhat similar to DTLS in a sense that it is
also unreliable and IKE *does* feature Dead Peer Detection.
I'm trying to implement IPFIX according to RFC 5101 which makes
support of DTLS on top of UDP mandatory for transmitting IPFIX
messages. That's why I'm surprised that there's no simple solution
to this problem.
Thanks
Daniel
Ger Hobbelt wrote:
On Mon, Jan 19, 2009 at 10:47 AM, Daniel Mentz <danie...@sent.com>
wrote:
Please note that I can not solve this problem via the protocol
that I use on
[...]
the fact the he does not send any data because he does not send
data anyway
(except Handshake messages like ServerHello, ServerKeyExchange,
etc.). I
guess IPFIX is a one-way protocol.
Well, though I agree with David Schwartz, the key operative word in
your text here is 'except' (see snippet of your text above). So the
server **does** send packets in return. (Gotcha. ;-) )
Given that you have a ServerKeyExchange or some such (I don't have
the
protocol documents for IPFIX around here so didn't check for the
feasibility of what I mention next), but the obvious hack I would
come
up with in such a scenario would be providing my own kind of 'keep
alive'; this time in the form of periodic requesting a new ServerKey.
(It would be a bit akin to SSL, where you can force a renegotiation.)
The idea here is that every N minutes or so, you 'renegotiate' a
keyset. That's the 'heartbeat' as when that renegotiation fails,
you'll know one of your nodes went belly up. Okay, so you lost an
undeterminable amount of data between previous key reneg and this
one,
but I'm sure one would be able to handle/hack that as well. ;-) (And
when we travel down this road, we arrive at where the TCP guys
already
are, as you are trying to convert a fire-and-forget protocol into a
guaranteed-delivery protocol.
And, just in case, when you say you don't have key renegotiation
options in the protocol, how do you come by a key set to start with?
I call the above a 'hack' because you are basically looking at
reimplementing TCP. (Plus IPFIX, but that's just too obvious, right?
;-) )
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
