Subject: RE: [Ipsec] INVALID_IKE_SPI

From: [email-masked]
Date: Tue, 28 Jun 2005 11:41:30 +0300

Hmm... regardless of where the SPI (or SPIs) is sent, it looks 
like the most useful piece of information for the the recipient 
of the INVALID_IKE_SPI notification is its own SPI, not the SPI 
of the party who sent the notification.

The recipient of the notification could have a large number of 
IKE_SAs with different peers, and some of those peers might have 
picked identical SPIs; but the SPI chosen locally uniquely 
identifies the IKE_SA in question.

Best regards,
Pasi

> -----Original Message-----
> From: Paul Hoffman
> Sent: Tuesday, June 28, 2005 6:41 AM
> To: IPsec WG
> Subject: [Ipsec] INVALID_IKE_SPI
> 
> 
> 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