On Mon, Feb 17, 2014 at 11:41 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > On a second read, I think my changes conflict with: > a1e3914fd0f469640a323da63715e8abf764a3a0 > > The latter sets the rekey method in TLS to be the same as the CSTP rekey > method, while in 14d807f58d2ca82f60505ef92115258c2d26da3f I assumed that > DTLS will have rekey method of NONE and will be reconnected at the CSTP > rehandshake/reconnect. Agreed - we can revert my change in dtls.c. It would be nice to have a block comment somewhere explaining why dtls_times.rekey_method == REKEY_NONE doesn't actually mean DTLS never gets rekeyed. Also, start_cstp_connection() can still change the DTLS parameters. I'd assume we need to call dtls_reconnect() unconditionally after cstp_reconnect() to allow for this, or go back to calling dtls_close() upon master secret regeneration. But it's OK to skip dtls_handshake() after cstp_handshake(), provided that dtls_times.rekey_method != REKEY_NONE. This still leaves the question of whether it is safe to rekey DTLS via dtls_reconnect() / dtls_try_handshake(), or if we actually need to send a new master secret first? What do the Cisco clients do? Maybe the master secret regeneration could be moved elsewhere. Absent a full CSTP reconnection, how should dtls_times.last_rekey get updated? If keepalive_action() only returns KA_REKEY for REKEY_TUNNEL, will the new REKEY_SSL logic in dtls.c ever run? FWIW I set a 4-minute rekey interval on my ASA, disabled all rekeying in openconnect, and ran it overnight with no obvious problems. But I would hate to break somebody else's configuration, because these "VPN quits passing traffic after 3 days" problems are very frustrating to debug.
