[strongSwan] StrongSwan Android App

[Tobias Brunner]

Hi Noel,

> I just noticed, that the strongSwan app still displays the tunnel as
> active, although a CHILD rekey event failed, because of a DH
> group/algorithm mismatch.

As long as the original CHILD_SA is still established the connection is
not broken, so displaying the connection as active is not incorrect.
When the SA later gets closed due to hard timeout the client tries to
recreate it and the state switches to "Connecting..." - but it will
probably fail again and will never recover from this state (unless
reauthentication is enabled on the server, which would force the client
to reestablish the IKE_SA after a while).

We can listen for ALERT_KEEP_ON_CHILD_SA_FAILURE to catch the rekeying
problem.  There are then two options to handle it:

  1. Simply report this as error state to the GUI.  I've implemented
     that with [1].

  2. Teardown the IKE_SA and reestablish in the hope that establishing
     the CHILD_SA with it will work (it did before since it's the
     rekeying that failed).  Implemented in [2].

I guess the latter results in a better user experience, although the
user might think the server configuration is actually used (e.g. if it
lists DH groups), which will not be the case.  But that might not be
that much of an issue as reestablishing the IKE_SA also provides PFS.

The client currently does not propose DH groups in the ESP proposal,
which has several reasons:

  1. ESP proposals are static because we currently have no API to query
     kernel interfaces for their supported algorithms.  It would be
     great to either add that, or at least have the option to define
     a proposal, to which all supported DH groups are added
     automatically.  The latter isn't that hard to implement but adding
     all supported DH groups to each proposal increases the size of
     CREATE_CHILD_SA exchanges quite a bit, especially because of the
     next issue.  Another problem is that we might want the algorithms
     in a certain order, which isn't handled well in the automatic
     default proposal.

  2. Proper support for NONE in the ESP DH proposals is missing (some
     support was added with 5.1.3, see [3]).  This would allow us to add
     NONE to the proposed DH groups, which would leave the decision
     to use PFS or not up to the responder.  Otherwise, if the user
     can't control the responder's config we'd have to either add a
     setting to enable/disable PFS, or propose all proposals once with
     and once without DH groups.  This increases the message size, also
     during the IKE_AUTH exchange as duplicate proposals are currently
     not filtered, fixed with [4]/[5].

  3. I honestly expected the VPN connections with the app to be rather
     short lived, so rekeying wasn't really in my focus (lifetime on
     the client is 3 hours).  But that might be a wrong assumption on
     my part.

Anyway, with [6] I added DH groups in the ESP proposals of the app.  But
the proposals are also added without DH groups so it's up to the
responder to choose a proposal with PFS (at the cost of larger messages).

All patches can be found in the android-child-rekey-failure branch and
will probably be included in the next release of the app.

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=b0af18547
[2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=c3edb1c0c
[3] https://wiki.strongswan.org/issues/532
[4] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=e74266e02
[5] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=b79236029
[6] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=108dd2c83