Re: How to detect dead peers with DTLS?
Hi Michael, unfortunately, you're wrong. You need my patches to perform renegotiations at all, since the current implementation is broken in this respect. Technically, the abbreviated handshake is supported, but OpenSSL does not provide any API to initiate it without reconnecting. The functions for session handling can be used to save a session and reassign it before connecting to perform an abbreviated handshake. This has no effect on an established connections because your saving and overwriting the session with the same data without any further action. I already criticized this in a mail to the list but there were no answers beside the explanation how to use the session functions when reconnecting. Regards, Robin Am 20.01.2009 um 18:38 schrieb Michael Tüxen: Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: 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. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http:// www.openssl.org User Support Mailing Listopenssl- us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
Hi Michael, since there seems to be no function, option or whatever to trigger session resumption for an established connection, I would have to modify the API to add this functionality. This is kind of critical because it would not only affect DTLS but also TLS which supports session resumption, too. In my opinion neither a DTLS specific method nor an untested generic method is a good solution. Regards, Robin Am 20.01.2009 um 19:42 schrieb Michael Tüxen: Hi Robin, what would be needed to add support for renegotiations in DTLS? Best regards Michael On Jan 20, 2009, at 7:01 PM, Robin Seggelmann wrote: Hi Michael, unfortunately, you're wrong. You need my patches to perform renegotiations at all, since the current implementation is broken in this respect. Technically, the abbreviated handshake is supported, but OpenSSL does not provide any API to initiate it without reconnecting. The functions for session handling can be used to save a session and reassign it before connecting to perform an abbreviated handshake. This has no effect on an established connections because your saving and overwriting the session with the same data without any further action. I already criticized this in a mail to the list but there were no answers beside the explanation how to use the session functions when reconnecting. Regards, Robin Am 20.01.2009 um 18:38 schrieb Michael Tüxen: Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: 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. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
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. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: 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. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to detect dead peers with DTLS?
I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? actually i referred to session resumptions with abbreviated handshakes. i think the bugs/patches comment was in the context of renegotiations with full handshakes. 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... _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
Hi Robin, what would be needed to add support for renegotiations in DTLS? Best regards Michael On Jan 20, 2009, at 7:01 PM, Robin Seggelmann wrote: Hi Michael, unfortunately, you're wrong. You need my patches to perform renegotiations at all, since the current implementation is broken in this respect. Technically, the abbreviated handshake is supported, but OpenSSL does not provide any API to initiate it without reconnecting. The functions for session handling can be used to save a session and reassign it before connecting to perform an abbreviated handshake. This has no effect on an established connections because your saving and overwriting the session with the same data without any further action. I already criticized this in a mail to the list but there were no answers beside the explanation how to use the session functions when reconnecting. Regards, Robin Am 20.01.2009 um 18:38 schrieb Michael Tüxen: Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: 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. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
On Jan 20, 2009, at 9:58 PM, Robin Seggelmann wrote: Hi Michael, since there seems to be no function, option or whatever to trigger session resumption for an established connection, I would have to modify the API to add this functionality. This is kind of critical because it would not only affect DTLS but also TLS which supports session resumption, too. In my opinion neither a DTLS specific method nor an untested generic method is a good solution. Understood and agreed. Regards, Robin Am 20.01.2009 um 19:42 schrieb Michael Tüxen: Hi Robin, what would be needed to add support for renegotiations in DTLS? Best regards Michael On Jan 20, 2009, at 7:01 PM, Robin Seggelmann wrote: Hi Michael, unfortunately, you're wrong. You need my patches to perform renegotiations at all, since the current implementation is broken in this respect. Technically, the abbreviated handshake is supported, but OpenSSL does not provide any API to initiate it without reconnecting. The functions for session handling can be used to save a session and reassign it before connecting to perform an abbreviated handshake. This has no effect on an established connections because your saving and overwriting the session with the same data without any further action. I already criticized this in a mail to the list but there were no answers beside the explanation how to use the session functions when reconnecting. Regards, Robin Am 20.01.2009 um 18:38 schrieb Michael Tüxen: Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: 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. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/ rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to detect dead peers with DTLS?
Hi everybody, how can I detect a dead server with *DTLS*? I'm developing an application (IPFIX exporter and collector) that only *sends* data using DTLS over UDP. Imagine the collector (DTLS server) crashes and comes up again. The exporter (DTLS client) does not notice the fact that the server went down and keeps on sending data using the old pre-master secret. The only thing the server can do is to drop those packets because due to the crash he lost the pre-master secret and also the whole state that constitutes the SSL object. Please note that the underlying protocol which is UDP - as opposed to TCP - does *not* tell me that the peer died. I might get some ICMP port-unreachable messages but I don't want to rely on that. Is there some kind of Dead Peer Detection like in the IPSec/IKE protocol that allows me to verify that my peer is still alive? In case the peer died I would just backup and initiate a new DTLS connection from scratch. Also, this mechanism would be useful to keep NAT mappings alive. Please note that I can not solve this problem via the protocol that I use on top of DTLS - which is IPFIX - because IPFIX - by definition - only *sends* but does not receive data. I.e. I can not infer that the server crashed from 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. Thanks Daniel __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to detect dead peers with DTLS?
Please note that I can not solve this problem via the protocol that I use on top of DTLS - which is IPFIX - because IPFIX - by definition - only *sends* but does not receive data. I.e. I can not infer that the server crashed from 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. Thanks Daniel You have a problem that cannot be solved in principle. If you do not allow the other side to ever send anything, then there is simply no way you can ever detect its absence. If you wish to detect the loss of the other side, the other side *must* send something. There is no other way. I suggest you either modify your protocol or layer another protocol between it and DTLS. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
Hi Daniel, why not use DTLS on top of SCTP? SCTP would check using its heartbeat mechanism whether the connection is still alive. Best regards Michael On Jan 19, 2009, at 10:47 AM, Daniel Mentz wrote: Hi everybody, how can I detect a dead server with *DTLS*? I'm developing an application (IPFIX exporter and collector) that only *sends* data using DTLS over UDP. Imagine the collector (DTLS server) crashes and comes up again. The exporter (DTLS client) does not notice the fact that the server went down and keeps on sending data using the old pre-master secret. The only thing the server can do is to drop those packets because due to the crash he lost the pre- master secret and also the whole state that constitutes the SSL object. Please note that the underlying protocol which is UDP - as opposed to TCP - does *not* tell me that the peer died. I might get some ICMP port-unreachable messages but I don't want to rely on that. Is there some kind of Dead Peer Detection like in the IPSec/IKE protocol that allows me to verify that my peer is still alive? In case the peer died I would just backup and initiate a new DTLS connection from scratch. Also, this mechanism would be useful to keep NAT mappings alive. Please note that I can not solve this problem via the protocol that I use on top of DTLS - which is IPFIX - because IPFIX - by definition - only *sends* but does not receive data. I.e. I can not infer that the server crashed from 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. Thanks Daniel __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
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? ;-) ) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
