Michael, i am curious, how would we detect DOS attack on server if someone sends too many such packets? dtls server would keep silently dropping them, will it report any error/status?
thanks, manish On Thu, Mar 15, 2012 at 6:16 PM, Michael Tuexen < [email protected]> wrote: > 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 < > [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] > > > > > > > > >
