[strongSwan-dev] High Availability

[Yaron Sheffer]

Hi,

we have an Internet draft that deals with exactly these issues: 
http://tools.ietf.org/html/draft-ietf-ipsecme-ipsecha-protocol-05

This is a bit late in the game (we are already past IETF Last Call), but 
I suggest that you take a look, and I would appreciate any comments.

Thanks,
	Yaron

On 04/22/2011 10:53 AM, Martin Willi wrote:
> Hi Daniel,
>
>> In the other hand, I don't get why a HA_IKE_ADD synchronization type
>> message would be generated from a "ike_keys" listener?  Could someone
>> help me on this?
>
> We follow the IKEv2 protocol relatively strict to synchronize IKE_SAs,
> we synchronize the information as soon as we get it. This allows us to
> keep as little additional state as possible for synchronization, and it
> was relatively easy to implement into the existing code base.
>
> The HA_IKE_ADD messages is triggered during the IKE_SA_INIT exchange,
> where the key material is generated. This won't synchronize a complete
> IKE_SA yet, just what we get during IKE_SA_INIT. After establishment, we
> pass all the remaining state using HA_IKE_UPDATE.
>
>> So I'm working on the transfer of a Security Association from one node
>> to another, for achieving this I'm taking ideas from the ha_plugin of
>> course.
>> My goal is not to synchronize every SA on a cluster but to take a SA
>> whenever I want and then been able to install it anywhere else.
>
> We explicitly synchronize only basic information for kernel level SAs,
> but not the sequence numbers. They are moving just to fast if you have
> traffic on the tunnel. If a node fails and you reuse the sequence
> numbers from a single second ago, your outgoing sequence numbers are
> already outdated and your traffic gets dropped. Therefore we use our
> extended ClusterIP functionality to keep sequence numbers in sync.
>
> Best regards
> Martin
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/dev