<div dir="ltr"><div>StrongSwan has a HA system that will synchronize the IKE and IPsec HA</div><div>state and so does not need to support RFC 6311 when StrongSwan is</div><div>configured as a HA cluster.</div><div><br></div><div>However, if the peer device is in a HA cluster and would prefer to use</div><div>RFC 6311 IKEV2_MESSAGE_ID_SYNC to synchronize the IKE SA message ID</div><div>counters then this will not work since StrongSwan does not support</div><div>responding to a IKEV2_MESSAGE_ID_SYNC message.  As to why the peer</div><div>device may prefer to use IKEV2_MESSAGE_ID_SYNC where possible,</div><div>consider the case where the peer is actually a small HA cluster of C</div><div>devices (say C=3) which act as VPN concentrators for N clients (say</div><div>N=60,000) and the traffic is uni-directional (from client to server</div><div>and so DPD on the client will continually being triggered due to lack</div><div>of traffic from concentrator end).  In this case the VPN concentrator</div><div>is receiving N/D DPD probes a second where D is the DPD period (say 5</div><div>seconds) and that could mean 12,000 IKE HAs a second that need their</div><div>sequence numbers synchronizing to the other cluster nodes.  That can</div><div>certainly be done, but that's a lot of traffic that can be avoided</div><div>if both sides support IKEV2_MESSAGE_ID_SYNC.</div><div><br></div><div>Attached is a patch</div><div>(0001-RFC-6311-IKEV2_MESSAGE_ID_SYNC-responder-support.patch) which</div><div>adds minimal RFC 6311 to StrongSwan.  Specifially with the patch</div><div>applied when StrongSwan initiates a connection then an</div><div>IKEV2_MESSAGE_ID_SYNC_SUPPORTED is uncondtionally included in the</div><div>IKE_AUTH.  If the peer responds with an</div><div>IKEV2_MESSAGE_ID_SYNC_SUPPORTED then StrongSwan is now prepared to</div><div>accept an INFORMATIONAL message containing an IKEV2_MESSAGE_ID_SYNC</div><div>and respond with a IKEV2_MESSAGE_ID_SYNC containing the updated</div><div>sequence numbers.</div><div><br></div><div>There patch does not include support for</div><div>IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, nor is there any support for</div><div>StrongSwan initiating IKEV2_MESSAGE_ID_SYNC on StrongSwan HA failover.</div><div><br></div><div>The patch was made against a tree containing the following at the tip :-</div><div><br></div><div>  commit d9fe0ec7122c1890836226f703a9774958876f3e</div><div>  Author: Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>></div><div>  Date:   Wed Aug 24 11:34:36 2016 +0200</div><div><br></div><div>      ikev2: (Re-)Queue tasks used to establish an IKE_SA in reset()</div><div><br></div><div>Note that RFC 6311 is rather invasive to the IKEv2 state machine since</div><div>it alters message ID numbers.  I've tried to fit in with the general</div><div>architecture of StrongSwan as best as I understand it.  For example,</div><div>I'm not entirely clear whether IKEV2_MESSAGE_ID_SYNC_SUPPORTED should</div><div>be handled as a task like IKEV2_MESSAGE_ID_SYNC or whether it is</div><div>acceptable to handle it in ike_auth.c.  I tried both and in the end</div><div>decided on putting IKEV2_MESSAGE_ID_SYNC_SUPPORTED in ike_auth.c since</div><div>it resulted in a smaller patch.</div><div><br></div><div>The patch was lightly tested against a Fortinet FortiGate.  I have</div><div>some debug showing the IKE SA negotiation, the FortiGate performing a</div><div>HA switch, sending IKEV2_MESSAGE_ID_SYNC to StrongSwan, receiving a</div><div>reply, re-synchronizing its sequence numbers and DPD in both</div><div>directions continuing to work.  However, my attempt to include</div><div>that in the submission pushed the email about the 100KB limit so</div><div>I've omitted them.</div><div><br></div></div>