[strongSwan] Dropped packets during CHILD_SA rekey

[Stuart Haslam]

Hi,

I have problem with ESP packets dropping during a CHILD_SA rekey.

The issue appears to be that the strongSwan client begins sending ESP
packets using the new CHILD_SA before it has sent the response to the
gateway\'s CREATE_CHILD_SA request. The gateway can\'t process these
packets until it receives the CREATE_CHILD_SA response, as soon as the
gateway receives the response things start working again. The time between
the client receiving the request and sending the response tends to be
around 3 seconds on my platform, I\'m not really sure where this delay
comes from.

According to the Rekeying section RFC 4306;

---
>From a technical correctness and interoperability perspective, the
responder MAY begin sending on an SA as soon as it sends its response
to the CREATE_CHILD_SA request. In some situations, however, this
could result in packets unnecessarily being dropped, so an
implementation MAY want to defer such sending.

The responder can be assured that the initiator is prepared to
receive messages on an SA if either (1) it has received a
cryptographically valid message on the new SA, or (2) the new SA
rekeys an existing SA and it receives an IKE request to close the
replaced SA. When rekeying an SA, the responder SHOULD continue to
send messages on the old SA until one of those events occurs.
---

Can anyone explain how this is intended to work in strongSwan, are either
of the two approaches described in the RFC implemented?

I\'m using strongSwan version 4.2.12 (with a few bug fixes backported) and
kernel 2.6.28.

Cheers,

Stuart.