(racoon 798) Dual, synchronous quick mode

[Yves-Emmanuel Jutard <ye.jutard@gmail.com>]

Hello,

I am a (french) NetBSD/Racoon user, and I have an IKE/IPsec problem.
It happens when, simultaneously, two hosts begin a quick mode with
each other, with the same parameters. Accoding to my experiments, it
ends with two SA created instead of one, which do not satisfy me.

Here is an example how to provoque such a behavior (synchronous quick
mode / phase 2), but it can happen naturally :

1) My two hosts are configured in transport mode, protecting all
protocols between themselves with one sp. They have the same
parameters (especially same lifetimes)

2) In my configuration, IPsec traffic has priority over IKE negociations.

3) For example, I send some data from host 1 to host 2 which provoque
an immediate reply from host 2 to host 1 (e.g. an UDP message to a
closed port, which leads to an ICMP "host unreachable" message)

4) Starting from nothing, I send such data over the network. An IKE
negociation starts, with a phase 1, then a phase 2, ending with the
creation of an IPSec SA. My data is lost, since at the time it should
have been sent, no corresponding IPsec SA was available. There are no
bufferisation while waiting for the SA to be negociated, so it's up to
my software to retransmit the data if necessary.

5) subsequent data are correctly encapsulated in IPsec, and everything
works well.

6) I come to the soft lifetime limit of the phase 2, wich happen
nearly simultaneously on both hosts. I send a message just after the
IPsec SA has reached its soft lifetime limit. The first message go
over the network (encapsulated in ESP with current IPsec SA), and then
a quick mode start from host 1, in order to renew its aging IPsec SA.

7) Host 2 receive the data, respond, and that response, in turn, leads
to the need for renewal of its IPsec SA.

8) So host 1 send a quick mode initiation, and at nearly the same
time, host 2 do the same. This lead to an imbricated, double phase 2
negociation : (taken from ethereal)

++++++> quick mode from host 1
------> quick mode from host 2

host 1                                   host 2

           ++++++++> quick mode 1 initiation
                   <------- quick mode 2 initiation
           --------> quick mode 2 response
(an IPsec SA is created on host 2 from quick mode 2)
                   <+++++++ quick mode 1 response
(an IPsec SA is created on host 1 from quick mode 1)
           ++++++++> quick mode 1 final
(an IPsec SA is created on host 2 from quick mode 1)
                   <------- quick mode 2 final
(an IPsec SA is created on host 1 from quick mode 2)


So we end with 2 IPsec SA, where only one was sufficient. It should
works, but it uselessly waste ressources !  How can I avoid this
phenomenon ? Is it normal or do I have done something bad ?

I have replicated the experiment between two Windows XP hosts (with
windows IKE/IPsec), but I have not seen any double negociation, only
one. How do windows avoid this ?

A look at racoon source (from NetBSD 1.6.0) shows that racoon reply to
every valid quick mode it receive, without checking if a corresponding
quick mode between the same hosts already exists. The two quick modes
are differenciated by their SPI, so there is no confusion between the
two concurrent quick modes.

Is my special need of IPsec which has priority over IKE negociations
the cause of this problem ? Maybe, but what If two hosts, by
misfortune, start simultaneously a negociation ? It statistically can
happen... I know that TCP can solve this problem by merging the two
initialisations into one (TCP/IP illustrated 18.8), but do IKE have
such a mecanism ?

Thanks for your responses, that's quite important to me.