[strongSwan-dev] [PATCH] charon: add optional source and remote overrides for initiate

[Timo Teras]

On Wed, 27 Aug 2014 10:17:11 +0200
Martin Willi <martin at strongswan.org> wrote:

> > This introduces support for specifying optional IKE SA specific
> > source and remote address for child sa initiation. This allows
> > to initiate wildcard connection for known address via vici.
> 
> I'm not sure if this is the right approach, as the change is rather
> invasive.

I remember having this discussion and suggestions earlier. But I think
it is a design flaw that initiation and responding work asymmetrically.
As this patch fixes a design issue, it can be a little bit invasive.
But I'd rather fix design issue then workaround it by duplicating
configs.

It is desirable (especially in dmvpn, but also in general case) to have
the connection specify a policy. And the option of manager connection to
state which IP-addresses to use for instance of that connection.

This is infact how things work in responder mode. The IKE_SA is
initiated based on first packet received, and then bound to matching
connection. I want this symmetry for initiator mode - as dmvpn design
benefits greatly of this. This would also reduce memory and resource
usage greatly. I'm planning solution where a single 'conn' entry would
have from 100s to 10.000s of instances - in mixed initiator and
responder roles.
 
> For other uses, we dynamically generate configuration objects to
> initiate with, without registering them at the backend. This is a
> little more consistent in behavior. The vici backend does currently
> not support initiating non-registered connections, but this could be
> definitely worth to add.

This would result in very ugly situation in dmvpn where
initiator/responder role is dynamic: part of connections would be
responders sharing a connection, and other part of connections are
initiators with cloned connections. It would be very hard or impossible
to detect if connections belong to same dmvpn mesh or not. An even
bigger problem happens when the role changes from initiator to
responder. It would mean migrating from forked config to the shared
responder config and lot of kludges in manager side to figure that out.

Additionally, I was planning to let all ike/child sa details go in
swanctl configs after all - thus bind to connection by name. This
would not be possible if configs need to be forked.

> @Tobias, what do you thing about this approach when looking at the
> trap-any branch? What is the state of that branch for mainlining?

As I mentioned in an earlier mail - I have rebased trap-any branch on
top of this.

I'll try to work on the other patches per received comments, and will
send a full patchset with the updated trap-sa patches as well.

Thanks for the feedback so far.