On Tue, 2014-02-11 at 21:37 +0100, Nikos Mavrogiannopoulos wrote: > On 02/11/2014 05:39 PM, David Woodhouse wrote: > > On Tue, 2014-02-11 at 16:35 +0100, Nikos Mavrogiannopoulos wrote: > >> > >> I think that the "ssl" rekey option of anyconnect suits better the > >> design of ocserv, as it allows for seamless rekey of both channels > >> (without breaking the connection). However, openconnect always assumes > >> the new-tunnel rekey method, and with this patch it is made aware of > >> the different options (and currently simply ignore the ones that are > >> unsupported). > > Do we actually know how the 'ssl' rekey method works for DTLS and CSTP > > with a Cisco server? > > According to their documentation it performs a rehandshake over the > session. That has to be verified with a cisco server though. > > For openconnect to support that (and test it), calling > gnutls_handshake() over an existing session would be sufficient. I have a *very* vague recollection of having tried that, and it not being sufficient. It's been a long time though. And it might only have been DTLS which stopped working; that required a rekey after 24 hours. Which made it very painful to test, of course. > > Previously, if the server asked for them, we'd fall back to tearing down > > the connection and making a new one (the 'new-tunnel' method). Now we do > > nothing... isn't that going to cause a problem? > > I don't think that the server would enforce that, but that's only my guess. ISTR I had users complaining that DTLS stopped working for the rest of the lifetime of the session, until I implemented the 'reconnect CSTP' method in commit 9d2b41dc8. But this was a long time ago and I've had two babies since then... -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140211/3bc1d78f/attachment.bin>
