On Mar 15, 2012, at 1:08 PM, Manish Yadav wrote: > Hi Michael, Robin, > > i had a basic doubt, suppose i have dtls client (ip address:cip, source port: > cport) and dtls server (ip address: dip, destination port: dport). both are > connected. then client goes down/crashes without calling ssl_shutdown, so > server still has the client context information. again client comes up and > uses same ip (cip) and port (cport) to establish ssl connection, since server > has already ssl context created (it thinks ssl is initialized) but receives > client hello? what is expected behavior in such scenario, does server starts > negotiation again or ignores client hello. Assuming that the client crashes and looses its state, the client will send an unencrypted client hello. Since it uses the same IP/port number, it will be processed by the server. But the server expects the client hello to be sent using the key material it has, it will be dropped. The server will keep its state. > > i was thinking what would happen if someone spoofs the client ip (cip) and > uses same port (cport) to establish connection with server (dip and dport), > could you please help me to understand how dtls deals with this? The attacker also needs to know the master secret to get the server to accept the packet...
Best regards Michael > > thanks, > manish > > On Sun, Feb 5, 2012 at 5:01 PM, Michael Tuexen > <michael.tue...@lurchi.franken.de> wrote: > On Feb 5, 2012, at 10:25 AM, Manish Yadav wrote: > > > Hi Michael, Robin, > > > > thanks for input. i was thinking if i am not implementing dtls heartbeat in > > that scenario, how could client detect if server is still getting the > > messages (assuming the server deleted inactive session after sometime or > > server got reloaded), is there any mechanism that could help here? > > > > i see > > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-02#section-3.1, > > which talks about similar problem (section3) and possible solution. > You need a mechanism in the application protocol. If you don't have that, > using > the heartbeats is (from my perspective) the next option. Please note that it > is part of OpenSSL 1.0.1 (currently in beta2) and the corresponding RFC will > be out soon (matter of days, I guess). > If you don't want to use the heartbeats, you can only renegotiate the DTLS > session > to see if the peer is still there. Please note that uses more resources than > the heartbeat stuff and it might affect the transfer of user messages. > > Best regards > Michael > > > > thanks, > > manish > > > > On Mon, Jan 30, 2012 at 1:10 PM, Robin Seggelmann > > <seggelm...@fh-muenster.de> wrote: > > On Jan 25, 2012, at 5:16 PM, Michael Tuexen wrote: > > > > > On Jan 25, 2012, at 2:21 PM, Manish Yadav wrote: > > > > > >> Hi Michael, > > >> > > >> thanks for quick response. i had one more question, is it possible to do > > >> decoupling of ssl object and socket fd to avoid rehandshake? (i am > > >> thinking to create socketfd only for active clients, if it is inactive > > >> for sometime then close the connection/socket and for inactive clients > > >> keep the ssl object cached, whenever inactive clients send data create > > >> new fd and associate with old ssl object, similar to > > >> http://net-snmp.sourceforge.net/dev/agent/snmpDTLSUDPDomain_8c_source.html). > > >> is it possible? > > > If you make sure that you don't send anything locally... > > > Why not close the DTLS connection after some time and let the client do a > > > new connect. You can cache the session > > > and the client can use session resumption. > > >> > > >> if i look at DTLSv1_listen, i am thinking i can not distinguish between > > >> active/inactive client? is it possible based on error value from > > >> DTLSv1_listen to tell if i received hello message or invalid message or > > >> invalid hello message/wrong cookie. > > > I don't think so. Robin? > > > > ClientHello messages are processed, so when the message or its attached > > cookie is invalid, an error will be returned. All other messages will be > > silently discarded and DTLSv1_listen() will not return, but simply wait for > > the next message. > > > > I'd also recommend session resumption for inactive clients. > > > > Best regards > > Robin > > > > > > >> thanks, > > >> manish > > >> > > >> On Wed, Jan 25, 2012 at 3:24 PM, Michael Tuexen > > >> <michael.tue...@lurchi.franken.de> wrote: > > >> On Jan 25, 2012, at 7:08 AM, Manish Yadav wrote: > > >> > > >>> Hi all, > > >>> > > >>> could you please confirm if dtls timers are implemented at client side > > >>> only and not on server side (only client retries/attempts to establish > > >>> connection) or why they should be implemented on server side also. > > >> You need timers on the server side also. However, > > >> DTLSv1_get_timeout/DTLSv1_handle_timeout is only necessary if you use > > >> select. > > >>> > > >>> > > >>> after looking at : http://crypto.stanford.edu/~nagendra/papers/dtls.pdf > > >>> > > >>> i understood that i need to call > > >>> DTLSv1_get_timeout/DTLSv1_handle_timeout incase of non-blocking socket. > > >>> but after looking at example available on net "dtls_udp_echo2.c", i see > > >>> only client side take care of this. i feel only client side should try > > >>> to reconnect, why server should try to resend message to client. > > >> Not sure about dtls_udp_echo2.c. You might want to take a look at the > > >> examples available at > > >> http://sctp.fh-muenster.de/dtls-samples.html > > >>> > > >>> please share if you know any example on this. > > >> Maybe Robin has more examples... > > >> > > >> Best regards > > >> Michael > > >>> > > >>> thanks, > > >>> manish > > >>> > > >>> > > >> > > >> ______________________________________________________________________ > > >> OpenSSL Project http://www.openssl.org > > >> Development Mailing List openssl-dev@openssl.org > > >> Automated List Manager majord...@openssl.org > > >> > > > > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > Development Mailing List openssl-dev@openssl.org > > > Automated List Manager majord...@openssl.org > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List openssl-dev@openssl.org > > Automated List Manager majord...@openssl.org > > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
