[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The current version of the clarifications document says:
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
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
Ipsec mailing list