>>>>> On Mon, 26 Jan 2009 18:19:02 +0100, Daniel Mentz <danie...@sent.com> said:
DM> I have some comments regarding your wiki article. But first of all DM> thanks for taking the time writing down all this information: Your welcome, and I'm sorry for taking so long to reply to your note... I was both sick for a week and out of town for a week and am just getting caught up again. (btw, I suspect if you followed the conversation that Robin's patches [1] to fix OpenSSL's DTLS handling are potentially much better than my hackary.) DM> I do not use a memory BIO for sending data. I create a datagram BIO DM> instead and let OpenSSL write to this datagram BIO directly. Yep, you're right that this would work as well. Outgoing wise, it's not an issue like it is incoming-wise. DM> When it comes to receiving data from the UDP socket I create a new DM> memory BIO for *each* packet I received via recvfrom() and pass that DM> memory BIO to OpenSSL. Hmm... ok, though I'm not sure why you can't reuse an existing BIO unless you're battling memory issues (which I suspect is the case). Either way, thanks for your notes on your implementation. DM> I've got a question regarding your solution for sending data: How do DM> ensure that the message boundaries are preserved? ... DM> What happens if the SSL_* function wants to send more than one UDP DM> datagram at once? I *guess* this could happen if someone wants to send DM> a very large certificate (chain). To me it seems like that you're DM> assuming that OpenSSL sends only a single packet during one invocation DM> of SSL_*, aren't you? If OpenSSL happens to send two packets you're DM> going to concatenate the payload and send out one large datagram DM> instead of two smaller ones. You're right... It technically should never happen according to the DTLS specs, *assuming* that the implementation isn't trying to send a second packet before waiting for the response to the first. The DTLS RFC requires that all DTLS messages must fit in a single UDP datagram and I doubt the internal implementation is sending multiple messages at once. But you're right, if it does try to I'm stuck as is and will fire both off in a single packet. On the bright side though, I suspect that if the other side is simply reading a bunch of data from the UDP socket and is openssl based it too will not care because the message boundaries on the incoming side are also ignored. This only works if both sides are equally broken and ignoring the UDP framing :-/ DM> As regards DTLS Cookie handling I suggest to ignore the information DM> hiding/data abstraction principle for now and to access OpenSSL's DM> internal variables in order to find out in which state the OpenSSL DM> state machine is right now. I guess that there's some way to find out DM> whether OpenSSL sent out a HelloVerifyRequest or a ServerHello. If it DM> just sent a HelloVerifyRequest we could just destroy the SSL object DM> and wait for the client to send back the Cookie. Yep. I've thought of that as well. sigh... but the right solution would be to fix the OpenSSL implementation. Footnotes: [1] http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes#Writing_a_new_UDP_BIO -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
