[Ipsec] INVALID_IKE_SPI

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

The current version of the clarifications document says:

6.11  INVALID_IKE_SPI

   Section 3.10.1 says that the INVALID_IKE_SPI notification "indicates
   an IKE message was received with an unrecognized destination SPI.
   This usually indicates that the recipient has rebooted and forgotten
   the existence of an IKE_SA."

   The text does not say whether the SPI value should be included in the
   notification.  However, it is clear that the notification will be
   useful to the recipient only if it can find the IKE_SA somehow, so
   the SPI should be included.

   This still leaves two questions open: which SPI(s) should be
   included, and how it (or they) should be sent.  For the first
   question, the alternatives are the unrecognized destination SPI, the
   source SPI (which presumably would be more useful for the recipient),
   or both.  For the second question, the SPI(s) could be placed in the
   SPI field(s) in the IKE header, the SPI field in the Notify payload,
   or the Notification Data field.

   In the case of another related notification, INVALID_SPI, the
   situation is clearer: there is only a single SPI, and the text
   explicitly says that the SPI is sent as Notification Data (since the
   notification is not about an existing SA, the SPI field in the Notify
   payload is not used; and obviously the value cannot be placed in the
   IKE header).

   Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA,
   and it is not about an existing SA, it seems that using Notification
   Data would be the logical choice.  However, this issue needs more
   discussion and we do not yet propose any solution in this document.

Do people agree with the conclusion (puting the SPI in the 
Notification Data)? And which SPI shoul be included?

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec