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