Subject: [IPsec] INVALID_IKE_SPI questions

From: Keith Welter <[email-masked]>
Date: Tue, 23 Sep 2008 12:56:44 -0700

For the one-way INVALID_IKE_SPI notification described in RFC 4306 section 
1.5, it is unclear to me what the Exchange Type should be in the IKE 
header.  Should it be 37 (INFORMATIONAL) or should it be copied from the 
request that contained the unrecognized SPI? 

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Sep 2008 13:42:05 +0300

>From RFC 4306 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.

As the text says you copy IKE SPIs and Message ID, I would interpret
that response being normal error response, meaning that the exchange
type is also copied. Perhaps this should be clarified in the IKEv2bis? 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Sep 2008 13:54:32 +0300

> type is also copied. Perhaps this should be clarified in the IKEv2bis?

I took it to be 37 (INFORMATIONAL) because it's an error message sent  
outside the context of an IKE SA, which CCSA should not be.

It's also more similar to INVALID_SPI like this, but that's probably  
not a good argument.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Sep 2008 07:47:38 -0700

I have opened this as issue #46. Clearly, it is a good question and 
there is disagreement about the answer. More responses are needed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 25 Sep 2008 15:46:00 -0400

> outside the context of an IKE SA, which CCSA should not be.

The main downside of this approach is that in the case of INVALID_IKE_SPI 
it's intended to be a response message (4306 says "MAY send a response," 
ikev2bis says it "is a response message"), and by tagging the response as 
having a different exchange but the same message ID as the original 
request message, it's quite possible that the original sender will simply 
discard this response as not matching any of its open exchanges, without 
ever reaching the point of processing the INVALID_IKE_SPI notify.  It 
seems to me that retaining the original exchange type will improve the 
likelihood of the original sender's processing the notify.

ikev2bis does say "MAY send an Informational message" for this case.  If 
we choose to have the INVALID_IKE_SPI case reuse the original request's 
exchange type, we should rewrite that phrasing so that it is clear that 
only the INVALID_SPI case necessarily has an Informational exchange type.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Yoav Nir <[email-masked]>
To:
Tero Kivinen <[email-masked]>
Cc:
[email-masked], Keith Welter/Raleigh/IBM@IBMUS
Date:
09/24/2008 06:55 AM
Subject:
Re: [IPsec] INVALID_IKE_SPI questions