[strongSwan-dev] High Availability

Yaron Sheffer yaronf.ietf at gmail.com
Sun Apr 24 12:15:31 CEST 2011


we have an Internet draft that deals with exactly these issues: 

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.


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

More information about the Dev mailing list