On Mar 16, 2012, at 8:31 AM, Manish Yadav wrote: > 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? Just dropping, no report.
Best regards Michael > > 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] > > > > > > > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
