[strongSwan-dev] Need clarification on INVALID-ID-INFORMATION notify message of quickmode negotiation

[Hussaina Begum Nandyala]

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" <tobias at strongswan.org> 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