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.
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? thanks, manish On Sun, Feb 5, 2012 at 5:01 PM, Michael Tuexen < [email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 > [email protected] > > >> Automated List Manager > [email protected] > > >> > > > > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > Development Mailing List [email protected] > > > Automated List Manager [email protected] > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List [email protected] > > Automated List Manager [email protected] > > > >
