Subject: [Ipsec] IKEv2 SPI unique or random ?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 22 Apr 2005 12:15:16 -0700

Hello,

The IKEv2 draft require the IKEv2 SPIs (the one that appears in the IKEv2 header) to be
unique so that it can be used to identify the IKE SA. But the first packet 
(SPIi =X, SPIr = 0) can carry the same SPIi from two different peers. For
example.,

Peer A sends to Peer B (SPIi = 5, SPIr = 0)
Peer C sends to Peer B (SPIi = 5, SPIr = 0)

If you use the SPIi alone to locate the SA, when you receive the packet from Peer C,
you would wrongly locate the IKE SA created by Peer A. Some implementations 
(though it locates the IKE SA wrongly) discard the packet later because it has
already processed the IKE_SA_INIT packet. So, the packet from Peer C will
be discarded. Some implementations might have a separate cache for initial packets
which would continue to discard for sometime till the cache expires.

If the SPIs are chosen randomly, then the probability of collision comes down and
hence the above issue does not arise. The other possibility is to use the "peer" address
also when locating the first packet alone which does not require the SPI to be chosen
randomly. If the peer address changes (NAT, mobility etc.) and the IKE_SA_INIT
packet is retransmitted, it would still not locate the wrong SA (just create another
entry).

How does implementations handle this case ? Perhaps the clarification document
could address this issue also..

-mohan

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Apr 2005 10:26:21 -0700

At 12:15 PM -0700 4/22/05, Mohan Parthasarathy wrote:
>hence the above issue does not arise.

That is how most implementations choose them, I suspect.

>could address this issue also..

We'll add a short bit about that.

--Paul Hoffman, Director
--VPN Consortium