Subject: [Ipsec] Problem with exchanges collisions

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 19 Dec 2005 09:26:30 +0100

Hi,

we have some problems when exchanges happen simultaeously. In order to
understand a possible case we attach an image. It's a posible case in
which extrange things may happen, a REKEY_IKE_SA exchange and a
REKEY_CHILD_SA exchange at the same time. In this case peers lose the
status sync.

We know it is unusual to attach images but it is very difficult to
explain in a textual format.

Best regards!
-- 
Alejandro Perez Mendez
Pedro J. Fernandez Ruiz

University of Murcia
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 19 Dec 2005 15:45:53 -0500

Interesting.  IMO this won't create a lasting problem, because the
rekey_ike_sa exchange is usually followed by a delete exchange for the
IKE SA.

After this delete exchange, the implementation on the right will lose
the "B" SA, while the left one will retain it.  Since it is the
implementation on the right that wanted this SA, it's safe to assume
that it will create a new one soon. Even if it doesn't, the worst that
could happen is that the left side will continue to use the "B" SA and
get an INVALID_SPI message.

OTOH the left implementation can fix this.  All it needs to do is to
refrain from accepting any child_sa exchanges on the IKE SA after it has
initiated the rekey. It can send the NO_MORE_SAS notification, and thus
fail the creation of B. When the right-hand side retries this, there
will be a new IKE SA and everything should work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alejandro Perez Mendez
Sent: Monday, December 19, 2005 3:27 AM
To: [email-masked]
Subject: [Ipsec] Problem with exchanges collisions

Hi,

Best regards!
-- 
Alejandro Perez Mendez
Pedro J. Fernandez Ruiz

University of Murcia

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Dec 2005 14:35:24 +0200

> rekey_ike_sa exchange is usually followed by a delete exchange for the

The problem is that if the peers go out of sync, then we really should
tear down the IKE SA and start over. The IKEv2 is supposed to make
sure the end nodes keeps on sync.

> will be a new IKE SA and everything should work.

I agree on that. When you start IKE SA rekey you need to mark the IKE
SA so that no new create childs will be allowed on it during or after
the IKE SA rekey (it is completely possible that the first create
child packet from the other end is lost, and we do get IKE SA rekey
finished before we even see that first packet).

I agree that NO_ADDITIONAL_SAS is perfect for this case, as it means
"responder is unwilling to accept any more CHILD_SAs on this IKE_SA".

The responder just needs to remember that it can retry recreating the
SA which failed with that error notify using another IKE SAs (i.e the
new one in this case). 
-- 
[email-masked]

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 20 Dec 2005 08:30:44 -0500

And yet the IKEv2 protocol has INVALID_SPI and INITIAL-CONTACT that
allows end nodes to re-sync if something went wrong. I don't think
receiving an INVALID_SPI is a good enough reason to tear down the IKE
SA.

I think Left should send a NO-MORE-SAS, but if it doesn't, Right should
not tear down the IKE SA, but rather respond with an INVALID SPI should
Left ever try to use the missed SA

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 

The problem is that if the peers go out of sync, then we really should
tear down the IKE SA and start over. The IKEv2 is supposed to make sure
the end nodes keeps on sync.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Dec 2005 16:30:33 +0200

> receiving an INVALID_SPI is a good enough reason to tear down the IKE

If the INVALID_SPI is received as a separate informational exchange
indicating that the other end received ESP or AH packet with SPI it
does not know, then of course you do not tear down the IKE SA. It is
completely possible that attacker is sending ESP and AH packets with
invalid SPIs. The receipient of the INVALID_SPI notify from the other
end should at most trigger DPD. In case the received INVALID_SPI had
protection of IKE SA, then there is no need to even do that. 

On the other hand if you get INVALID_SPI error message as a response
IPsec SA rekey or delete notification you have sent out, that means
that there is something wrong with the state of the IPsec SAs in two
peers. This is expected in some cases (like if window size is > 1 and
the other end has not yet processed some of those messages, or in
cases where there is exchanges going in both directions and the other
is using SPI created by the exchange not finished yet), but if the
problem does not disappear in few minutes, then it indicates that the
state of the two ends is out of sync (i.e. you send DELETE SPI 1234,
and got INVALID_SPI error back, you retry that after 3 minutes, and
still get DELETE SPI 1234 back, then you know there is something
permanently out of sync in the peers, and you should restart the IKE
SA from the beginning).

If you do not do that you create black hole which will cause traffic
to be silently dropped.

> Left ever try to use the missed SA

I think it is better to say that left MUST send NO_ADDITIONAL_SAS.
I.e. forbid creating new SAs on the IKE SA which is already in the
progress of being rekeyed.

Yes, the right will also send INVALID SPI to the left end if it
receives packet with the SPI it does not know. When left receives
INVALID SPI with the SPI value it knows should be valid, then it will
suspect that the two ends are out of sync, and it will restart the IKE
SA.

The problem with state getting messed up means that we do have black
hole which will drop packets sent to it. We do want to recover from
that, which means we do want to restart the IKE SA to make sure we
clear out all black holes. We cannot recover from black holes by
sending deletes and so on, as we do not know how the state is messed
up, thus we need to start from the beginning. 
-- 
[email-masked]