Subject: [Ipsec] INVALID_IKE_SPI

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jun 2005 20:40:47 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 28 Jun 2005 18:08:54 -0700

In section 2.21,
   If a node receives a message on UDP port 500 or 4500 outside the
   context of an IKE_SA known to it (and not a request to start one), it
   may be the result of a recent crash of the node.  If the message is
   marked as a response, the node MAY audit the suspicious event but
   MUST NOT respond. If the message is marked as a request, the node MAY
   audit the suspicious event and MAY send a response. If a response is
   sent, the response MUST be sent to the IP address and port from
   whence it came with the same IKE SPIs and the Message ID copied. The
   response MUST NOT be cryptographically protected and MUST contain a
   Notify payload indicating INVALID_IKE_SPI.

This says, that the IKE header has the SPIs just copied back. You also
have to copy back the "Initiator" flag so that the receiver of the notification
can locate the SA appropriately.

-mohan