Subject: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)?

From: Yaron Sheffer <[email-masked]>
Date: Tue, 3 Mar 2009 20:18:27 +0200

1.5. Informational Messages outside of an IKE_SA

...

{{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should only be used by the recipient as a 'hint' that something might be wrong (because it could easily be forged).

Tero:

If the notification data is used for the SPI of the invalid packet, how can the recipient of such notify know whether that SPI was for ESP or AH? As far as I can see, it cannot, but I think it does not matter as SPIs are now supposed to be unique (i.e. protocol is no loger include as key). Perhaps we should just note this fact here?

Paul: Not done. This is interesting, but should be discussed on the list.

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 13:24:04 +0100

Hmm... it seems Tero is right; since the SPI is in the notification
data (not the "SPI" field of the Notify payload), the "Protocol ID"
field would be zero, and the recipient doesn't know whether the SPI
was for ESP or AH.

I think Tero's proposal about just noting this fact (i.e. not 
changing how this work) would be OK and sufficient.

Best regards,
Pasi

> -----Original Message-----
> From: Yaron Sheffer
> Sent: 03 March, 2009 20:18
> To: [email-masked]
> Subject: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)?
> 
> {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE
> INFORMATIONAL exchange when a node receives an ESP or AH packet with
> an invalid SPI. The Notification Data contains the SPI of the
> invalid packet. This usually indicates a node has rebooted and
> forgotten an SA. If this Informational Message is sent outside the
> context of an IKE_SA, it should only be used by the recipient as a
> 'hint' that something might be wrong (because it could easily be
> forged).
> 
> Tero:
> 
> If the notification data is used for the SPI of the invalid packet,
> how can the recipient of such notify know whether that SPI was for
> ESP or AH? As far as I can see, it cannot, but I think it does not
> matter as SPIs are now supposed to be unique (i.e. protocol is no
> loger include as key). Perhaps we should just note this fact here?
>

---

From: Joy Latten <[email-masked]>
Date: Wed, 11 Mar 2009 13:29:16 -0500

> changing how this work) would be OK and sufficient.

I could be missing something, but RFC4301, section 4.1 allows
implementations to use the SPI in conjunction with the IPsec protocol
for SA identification. So, if someone is in that latter case, wouldn't
they have a problem? 

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 11:14:10 +0100

> for SA identification. So, if someone is in that latter case, wouldn't

Well... depends on whether the recipient of the notification actually
uses the SPI value for something (other than possibly debugging/logging).

The "INVALID_SPI" notification basically means "I've rebooted, or our
understanding of IPsec/IKEv2 state is otherwise screwed up".  If this
was an unprotected one-way notification, the recipient would it as a
hint that things might be wrong, and initiates a liveness test for the
IKE_SA.  If it was a protected notification, it probably means an
implementation bug somewhere, and a possible action would be to create
a new IKE_SA (and new CHILD_SAs) from scratch. In neither case, the
recipient really needs the SPI value for anything..

Best regards,
Pasi

---

From: Joy Latten <[email-masked]>
Date: Fri, 13 Mar 2009 15:02:43 -0500

> recipient really needs the SPI value for anything..
Ah, ok, that is true. That makes sense. Thanks for explaining. 

regards,
Joy