[strongSwan-dev] IKE1 and "service" type of application

[Martin Willi]

Hi Alexander,

> All of presented clients fixed on IKEV2 protocol SA from the 
> beginning. Does it means usage of IKEV1 is not possible in this scheme 
> of controlling service?

IKEv1 connections can be handled exactly the same way with strongSwan
5.x, you identify the protocol version to use with the version parameter
in ike_cfg_create().

> My current problem with IKEV1 and android client concerning 
> distribution of auth rules over peer_cfg_t and ike_sa_t structures.

You should never add any auth_cfgs or rules to the IKE_SA, the daemon
does this for you. Configuration happens through the peer_cfg and
associated objects, only.

Each auth_cfg represents an authentication round done by the local or
the remote peer. IKEv2 can do multiple rounds using the Multiple
Authentication extension.

IKEv1 can do a single round only for traditional authentication, and the
local and remote rounds must use the same method (PSK or public key).
With the XAuth extension, you can add another round for the client using
the XAuth method; Hybrid authentication allows you to replace the first
round with XAuth.

> It is possible to fill ike_sa_t with all needed rules right from the 
> beginning (initiate() of android_service.c) but I don't think it is a 
> right way to solve this problem.

You really should avoid that. You configure auth_cfgs on your peer_cfg,
and initiate that connection. The daemon takes care of processing your
rules, and merges them to the IKE_SA as needed.

Regards
Martin