Hi Nilesh, On 09.02.2011, at 17:15, Nilesh Vaghela wrote:
> Just wanted to give additional information that I am not implementing > multi-threaded server as there can be thousands of connections. Having said > that I would have to use select for both the fds (one listen socket and many > connected sockets). With this model, do I still have to handle DTLS timers ? > The way I was thinking of implementing is > to have read interest on the listen fd and when it gets triggered call > DTLSv1_listen and of it returns -1 then keep the interest and call > DTLSv1_listen again when read fd is triggered. At the same time I would also > have other connected fds in the (read/write) fdset for select. Will this > works like that ? You have to handle the timers for every single DTLS connection. > 1. I assume that >= 1.0.0a version has FIPS support fro DTLS ? > 2. What is the difference between 0.9.8 and 1.0.0 ? Assuming that program > tested with 0.9.8 (with FIPS) would work without any changes on 1.0.0. 1. Probably not. The DTLS implementation was a proof of concept and we provided as many patches as necessary to get it running and compliant to RFC 4347. I don't think anyone took care about FIPS yet. 2. The latest bugfixes have not been backported because the differences between the versions became too large. In 0.9.8 you don't have IPv6 support, the replay handling is erroneous, the reassembly is entirely broken and many other things. Have a look at http://sctp.fh-muenster.de/dtls-patches.html, there are pretty much all of the recent DTLS patches listed and only very few have made their way into the 0.9.8 branch. > I just realized that may be DTLSv1_get_timeout and handle timeout is > important because when server sends Server Hello we need to get back the > response in time out. > Is that right understanding ? If that is the case then in select I can not > mix other fds as the may get activity before timeout of DTLS. You're right. You need to handle the timeouts for every DTLS connection separately. That's why threads are recommended. > How does DTLSv1_listen handle multiple ClientHellos at the same time, let us > say multiple clients are connecting. > It looks like unless for one client hello session is not completed it can not > start hello session for other client. > I understand this way because we have to call DTLSv1_handle_timeout() in > order to update the timer in SSL library for > retransmission of Hello. My understanding may be wrong. I would appreciate if > some one clarifies. You can handle multiple connection attempts with DTLSv1_listen. The call will answer ever ClientHello with a ServerHello and returns if a ClientHello has been repeated with the cookie. Since its socket will then be replaced, an other connection attempt only gets lost if two ClientHellos with a cookie arrive at the exact same time and there was no chance to exchange the socket in the meantime. Then one ClientHello can't be processed and has to be retransmitted. The cookie generation and verification works even if the SSL object was exchanged in between, because it's done with independent callback functions. You don't need to care about timeouts at this point because the DTLSv1_listen will not start any timers. It's supposed to prevent denial of service attacks so it only responds to incoming ClientHellos and either returns if a verification was successful or just continues. The client will have a timer and repeats the ClientHello if anything gets lost. You will need the timer handling for the connected socket after the ClientHello, when the handshake is completed as well as for renegotiations. It's done this way because the OpenSSL API does not allow one-to-many sockets to be used, which would be the actual way to work with UDP instead of creating many connected sockets. To supply a destination with e.g. a SSL_read(), significant changes to the architecture would have to be made. To avoid that, the workaround with connected UDP sockets is used to "emulate" a one-to-one scenario similar to TCP. Best regards Robin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
