I agree that the rekeying is a timing issue. In the Linux-Linux case
I wrote about earlier, it was easy to see. But in the following case,
I have used a Linux-Windows(XP) setup; I see it a bit differently.
Linux host: 192.168.18.1 (IPsec-tools 0.7.1)
Windows host: 192.168.18.99 (Windows XP SP2)
IPsec Transport Mode, racoon setting: passive=off on Linux side.
The following is an observation upon sending a ping request from the
Windows host (192.168.18.99) to the Linux host (192.168.18.1).
------------ 8< ------------- racoon.log on 192.168.18.1 -----------
*15:22:12: INFO: initiate new phase 1 negotiation:
*15:22:12: INFO: begin Identity Protection mode.
*15:22:19: INFO: respond new phase 1 negotiation:
*15:22:19: INFO: begin Identity Protection mode.
15:22:19: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
15:22:19: INFO: received Vendor ID: FRAGMENTATION
15:22:19: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
*15:22:19: INFO: ISAKMP-SA established
15:22:19: INFO: respond new phase 2 negotiation:
**15:22:19: INFO: IPsec-SA established: ESP/Transport
15:22:19: INFO: IPsec-SA established: ESP/Transport
*15:22:20: INFO: isakmp_chkph1there calling isakmp_ph2begin_i
**15:22:20: INFO: initiate new phase 2 negotiation:
*15:22:20: WARNING: attribute has been modified.
15:22:20: WARNING: ignore CONNECTED notification.
15:22:22: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
15:22:22: INFO: received Vendor ID: FRAGMENTATION
15:22:22: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
*15:22:22: INFO: ISAKMP-SA established
15:22:30: ERROR: wrong state 8.
15:22:30: ERROR: failed to pre-process packet.
15:22:40: ERROR: wrong state 8.
15:22:40: ERROR: failed to pre-process packet.
15:22:50: ERROR: 192.168.18.99 give up to get IPsec-SA due to time up to
------------ 8< ---------------------------------------------------
1. Linux host initiates phase 1 (15:22:12)
2. Windows host also initiates phase 1, the Linux host responds
3. Phase1 ISAKMP-SA is established
4. Windows host initiates phase 2 and the Linux host responds
5. Phase2 IPsec-SAs are established successfully as seen in the
6. Now at 15:22:20, the Linux host initiates *phase2* even though
IPsec-SAs are already established
7. Interestingly, at 15:22:22, ISAKMP-SA is established again and
then 'wrong state 8' errors are seen.
Any idea what these 'wrong state 8' errors are?
In this case, the race is not very obvious, as the Linux host seems
to have the chance to avoid phase2 initiation. Look at the debug
statement at 15:22:20 (isakmp_chkph1there calling isakmp_ph2begin_i).
If this is confirmed a race, I will come up with a patch to fix
Timo Teräs wrote:
> Tushar Gohad wrote:
>> When using transport mode IPsec between two Linux hosts using racoon,
>> I have configured racoon on both the hosts with 'passive off.' Thus
>> both the sides can initiate a Phase1/Phase2 negotiation.
>> I see in the racoon log, that when one side starts Phase1 negotiation,
>> the other side also initiates the same. In the end, even if one side
>> has finished with Phase2 IPsec-SA establishment, the other side still
>> goes ahead and establishes new Phase2 IPsec-SAs.
> racoon inititates a phase1/2 when kernel asks to do so by sending a
> pfkey acquire. If both sides want to send traffic to the other party
> at the same time, you are likely to end up having two phase2:s.
>> Why does racoon (running on either side) not check if Phase2 IPsec-SA
>> are already established before reestablishing the same again?
> It's a timing issue. There's no easy way to get rid of this easily.
> There's some precautions we can do, but it's easy to get it wrong.
> We could check if there's being negotiated a phase2 for the same
> leg and retain initiation in that case in isakmp_chkph1there(). This
> would reduce the probability to get multiple phase2:s negotiated
> quite a bit, but there would still be a possibility for that if
> both sides sent the ph2 negotiation 1st message at the same time.
> We definitely should prevent rekeying of both phase2:s. E.g. rekey
> phase2 only if we are initiator (as now) _and_ if there is no other
> established phase2 either (not checked atm).
>> Is this standard behavior or just the ipsec-tools implementation?
> Mostly ipsec-tools implementation. But I would not be surprised if other
> implementations did the same.