[PULL request] distinguish between different rekey methods

[David Woodhouse]

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>