[PULL request] distinguish between different rekey methods

[Nikos Mavrogiannopoulos]

On 02/16/2014 05:41 AM, Kevin Cernekee wrote:
> On Fri, Feb 14, 2014 at 11:51 PM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> I noticed that this pattern is on several other logs posted before. So
>> it seems that anyconnect handle the rekey of the TLS channel and simply
>> reconnect the DTLS channel at the same moment (I see that there isn't
>> even a configuration option to change the rekey time of DTLS).
> 
> When comparing your new rekey code to what is in the existing
> start_cstp_connection(), it occurred to me that we may be operating
> under different assumptions:
> In your experimentation with Cisco AnyConnect clients, do you see them
> sending a brand new DTLS master secret during rekey (ala commit
> 9d2b41dc8) or merely re-handshaking / re-establishing the DTLS session
> in order to generate new session keys?

If I set the Rekey-Method to 'ssl' the process is:
1. The CSTP channel performs a rehandshake
2. The DTLS channel is disconnected, and reconnects (using the same key
- there is no way to negotiate a different key - but different nonces).
That is pretty much equivalent to a rehandshake.

What I'm trying to optimize there in the 'rekey' branch of openconnect-x
is to allow a simple rehandshake if X-DTLS-Rekey-Method is set to 'ssl'.
That way there will be no need to disconnect and reconnect the UDP channel.

That is needed because ocserv needs to transfer each new UDP connection
to the handling process, something that is quite cumbersome in Linux and
only works serialized (meaning if many connections reconnect at the same
time some may timeout).

> To address your other point, I have found that many of the X-CSTP-*
> and X-DTLS-* options have identical values and cannot be configured
> independently on the ASA.  On my box, compression is the only option
> that allows separate settings under "anyconnect dtls <opt>".

That is my understanding too. The rekey-time should be handled the same
in AnyConnect clients for both TLS and DTLS even if it is sent twice.

regards,
Nikos