On Wed, 27 Aug 2014 10:17:11 +0200 Martin Willi <[email protected]> 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. _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
