[GIT PULL V4] JNI bindings for libopenconnect

Nikos Mavrogiannopoulos nmav at gnutls.org
Tue Jan 21 12:17:28 EST 2014


On 01/21/2014 05:34 PM, Woodhouse, David wrote:
> On Tue, 2014-01-21 at 08:02 -0800, Kevin Cernekee wrote:
>> On Tue, Jan 21, 2014 at 2:47 AM, Nikos Mavrogiannopoulos
>> <nmav at gnutls.org> wrote:
>>> I have not tried yet, but a question on that. On the CSTP reconnect is the
>>> DTLS channel kept open or it is also re-opened? If it is kept opened then
>>> the warnings you see are normal as ocserv handles the CSTP channel as
>>> control and once discarded the DTLS channel is discarded as well.
>>
>> The old behavior was to keep it open.  The new behavior is to
>> close+reopen DTLS on CSTP reconnect.
> 
> Hm, is that necessary?
> One of the reasons why a VPN should run over UDP instead of TCP is
> because TCP connections stall when there's packet loss. So on a crappy
> connection you *do* end up with CSTP reconnects due to aggressive DPD,
> while the DTLS is still quite happily running.

Does this really happen? How could a DPD over the TLS channel be lost?
I'd expect the DPD over the UDP channel to fail but not the other way round.

Since ocserv keeps that state of the TLS sessions in a different process
than the main server there is no (easy) way to transfer that state to a
new process once the client reconnects. So I don't think ocserv will
support keeping the DTLS channel on any time soon. There could be a way
to transfer the new TCP session to the existing client, but it is
impossible to associate them (especially if TLS session resumption isn't
being used).

> I seem to recall that my testing, back when this was first implemented,
> seemed to show that DTLS would happily keep going even while the CSTP
> was reconnecting, with no loss of service. 

Is a TCP reconnect required for the rekey? I believe that simply a TLS
rehandshake over the same TLS channel would be sufficient for a rekey
(and just modified ocserv to handle that). The DTLS channel though
cannot be rekeyed like that due to the peculiar way it is being established.

btw. how is the DTLS channel being rekeyed if it stays open during the
TLS rekey? DTLS requires rekey even sooner than TLS (2^48-1 packets
instead of 2^64-1).

regards,
Nikos




More information about the openconnect-devel mailing list