Subject: [IPsec] SPI Collision

From: Daniel Migault <[email-masked]>
Date: Thu, 5 Apr 2012 20:22:40 +0200

Hi,

I am wondering how SPI collision is considered by IKEv2, and have not found
any documentation on it, so if there are some, please let me know.

My current understanding is that when an CREATE_CHILD_SA exchange is
performed the Initiator and Responder announce the SPI in the SA payload.
If the Initiator announces an SPI that is already used by the Responder
(with another peer), the Responder cannot accept this proposition and must
send an error message. I haven't found anything like this in RFC5996. Am I
missing something ?

Furthermore I cannot find any message for this error. INVALID_SPI does not
seems to be used for the creating of an SPI, but only if an ESP/AH/IKE
packet comes with an unrecognized SPI. In addition it seems the Notify
Payload MUST be sent out of the IKE_SA.... Can anyone tell me which error
message is used?

BR
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Apr 2012 22:15:53 +0300

Hi Daniel

On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote:

> Hi, 
> 
> I am wondering how SPI collision is considered by IKEv2, and have not found any documentation on it, so if there are some, please let me know.
> 
> My current understanding is that when an CREATE_CHILD_SA exchange is performed the Initiator and Responder announce the SPI in the SA payload. If the Initiator announces an SPI that is already used by the Responder (with another peer), the Responder cannot accept this proposition and must send an error message. I haven't found anything like this in RFC5996. Am I missing something ?
> 
> Furthermore I cannot find any message for this error. INVALID_SPI does not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE packet comes with an unrecognized SPI. In addition it seems the Notify Payload MUST be sent out of the IKE_SA.... Can anyone tell me which error message is used? 
> 
> BR 
> Daniel

In IKE (both v1 and v2) it's always two IPsec SAs that are negotiated at the same time. Each side sends in its CCSA message the SPI for the inbound SA. So for traffic going from the initiator to the responder, it's the responder that chooses the SPI, while for traffic going from the responder to the initiator, the initiator chooses the SPI. This allows both peers to make sure that inbound SAs have unique SPIs.

The same guarantee cannot be made for outbound traffic. The SPI for outbound traffic is chosen by the peer, and one particular implementation that I'm aware of assigns them serially, so with many peers like that, you have a high chance of collision. The fact is that it is usually not a problem. In outbound IPsec processing the stack sees the cleartext packet, chooses an SA based on attributes of the packet, and constructs the protected packet based on encryption keys, MAC keys, the replay counter and the SPI which are part of the SA. The SPI is a value, not a key in the table of outbound SAs, so there's no harm done even if all the outbound SAs have the same SPI. 

This is different from the inbound case, where the SPI is used as a key to the SA table, and therefore has to be unique.

Hope this helps

Yoav

---

From: Daniel Migault <[email-masked]>
Date: Mon, 9 Apr 2012 20:08:42 +0200

Hi Yoav,

Thank you very much for your answer. It does fully answer my question!

BR,

Daniel

On Thu, Apr 5, 2012 at 9:15 PM, Yoav Nir <[email-masked]> wrote:

> > I am wondering how SPI collision is considered by IKEv2, and have not
> found any documentation on it, so if there are some, please let me know.
> >
> > Furthermore I cannot find any message for this error. INVALID_SPI does
> not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE
> In IKE (both v1 and v2) it's always two IPsec SAs that are negotiated at
> the same time. Each side sends in its CCSA message the SPI for the inbound
> SA. So for traffic going from the initiator to the responder, it's the
> responder that chooses the SPI, while for traffic going from the responder
> to the initiator, the initiator chooses the SPI. This allows both peers to
> make sure that inbound SAs have unique SPIs.
>
> The same guarantee cannot be made for outbound traffic. The SPI for
> outbound traffic is chosen by the peer, and one particular implementation
> that I'm aware of assigns them serially, so with many peers like that, you
> have a high chance of collision. The fact is that it is usually not a
> problem. In outbound IPsec processing the stack sees the cleartext packet,
> chooses an SA based on attributes of the packet, and constructs the
> protected packet based on encryption keys, MAC keys, the replay counter and
> the SPI which are part of the SA. The SPI is a value, not a key in the
> table of outbound SAs, so there's no harm done even if all the outbound SAs
> have the same SPI.
>
> This is different from the inbound case, where the SPI is used as a key to
> the SA table, and therefore has to be unique.
>
> Hope this helps
>
> Yoav
>
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58