Hi Tobias, (1)We are supporting ikev1 for backward compatibility. (2)We are using strongSwan 5.3.5 We(Initiator) send IDii/IDir payload, which does not match any subnet in the strongSwan(responder mode) and strongSwan sends INVALID-ID-INFORMATION notification. However the SPI value is set to 0, though the spi length is set to 4 in the notification payload. How can initiator map this notification payload to any IKE SA without the SPI information ? I am referring to the quick_mode.c's send_notify() function, where the set_spi() function is called to set the SPI's from phase 2 structures, which are not allocated yet. Shouldn't the SPIs be fetched from phase1 in this case (IDii/IDir mismatch case)?
(3) Ignore the table. I was interested in the N(INVALID-ID-INFORMATION)'s SPI values (in the quickmode exchange). Regards, Hussaina N. On 11/5/18, 10:01 PM, "Tobias Brunner" <[email protected]> wrote: Hi Hussaina, Any particular reason you are using IKEv1? You should just switch to IKEv2 to avoid any such issues. > With IKEv1, when strongSwan(as responder) sends INVALID-ID-INFORMATION > for IDii/IDir mismatch, it does not send SPI value of IKE SA. However, > it sends 0 SPI in the quickmode negotiation along with HASH payload and > N(INVALID-ID-INFORMATION). If you are referring to a mismatch in traffic selectors during Quick Mode, then I can't confirm that. The INFORMATIONAL sent by strongSwan contains both SPIs (or "Cookies") in the IKE header in my tests, and it is processed accordingly by the IKE_SA of the initiator. What strongSwan version are you using? > Can someone clarify, whether strongSwan should send valid SPI with the > N(INVALID-ID-INFORMATION) or not ? Hm, are you referring to the column captioned "SPI" in the table in section 2.4 of RFC 2408? If so, then definitely not. That refers to the SPI field in the Proposal payload (section 3.5 in the RFC). Since there is no such Payload in the INFORMATIONAL error response, there is also no SPI field to set. Regards, Tobias
