On 02/18/2014 07:08 AM, Kevin Cernekee wrote: > 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, dtls_reconnect() follows the cstp_reconnect() call as it is now from the cstp_mainloop. I don't think they should be completely merged, because in the use-case the dtls_reconnect only occurs if the dtls rekey method is set to none. > 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. We don't to generate a new key for a rekey process. The reconnection (and subsequent handshake) ensures that the final DTLS key will be different (will also depend on the nonces of the handshake). > Absent a full CSTP reconnection, how should dtls_times.last_rekey get updated? It is updated by keepalive_action() when sending the KA_REKEY command. > If keepalive_action() only returns KA_REKEY for REKEY_TUNNEL, will the > new REKEY_SSL logic in dtls.c ever run? There is something fishy there indeed. It should be != REKEY_NONE. I've updated that. I've tried to fix the open issues, and make it a bit more resistant to failures (if DTLS rehandshake it will now reconnect). > 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. Without rekey one can transfer 2^48 DTLS packets before the TLS connection terminates. That's an enormous amount for 3 days though. regards, Nikos
