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

[Hussaina Begum Nandyala]

Hi,

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).
As per https://tools.ietf.org/html/rfc2408#section-2.4, this response message should under line no(4). I think, line(5) is for KE/ID payloads of main mode.

Can someone clarify, whether strongSwan should send valid SPI with the N(INVALID-ID-INFORMATION) or not ?

# Operation I-Cookie R-Cookie Message ID SPI
(1) Start ISAKMP SA negotiation X 0 0 0
(2) Respond ISAKMP SA negotiation X X 0 0
(3) Init other SA negotiation X X X X
(4) Respond other SA negotiation X X X X
(5) Other (KE, ID, etc.) X X X/0 NA
(6) Security Protocol (ESP, AH) NA NA NA X


Here is the snip of the packet trace (strongSwan peer is 1.1.5.100) –
IKEv1 packet S(192.168.128.1:500 -> 1.1.5.100:500): len= 216, mID=00000000, HDR, SA, Vid, Vid, Vid, Vid, Vid, Vid
IKEv1 packet R(192.168.128.1:500 <- 1.1.5.100:500): len= 148, mID=00000000, HDR, SA, Vid, Vid, Vid
IKEv1 packet S(192.168.128.1:500 -> 1.1.5.100:500): len= 356, mID=00000000, HDR, KE, Nonce, PRV, PRV
IKEv1 packet R(192.168.128.1:500 <- 1.1.5.100:500): len= 372, mID=00000000, HDR, KE, Nonce, PRV, PRV
IKEv1 packet S(192.168.128.1:500 -> 1.1.5.100:500): len= 92, mID=00000000, HDR, ID, HASH, N(INITIAL_CONTACT)
IKEv1 packet R(192.168.128.1:500 <- 1.1.5.100:500): len= 76, mID=00000000, HDR, ID, HASH
IKEv1 packet S(192.168.128.1:500 -> 1.1.5.100:500): len= 460, mID=8956a6b8, HDR, HASH, SA, Nonce, KE, ID, ID
IKEv1 packet R(192.168.128.1:500 <- 1.1.5.100:500): len= 76, mID=bd816a46, HDR, HASH, N(INVALID_ID_INFORMATION)


Thanks & Regards,
Hussaina N.

[Tobias Brunner]

Hi Hussaina,

Any particular reason you are using IKEv1? You should just switch to
IKEv2 to avoid any such issues.

Post by Hussaina Begum Nandyala
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?

Post by Hussaina Begum Nandyala
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

[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" <***@strongswan.org> wrote:

Hi Hussaina,

Any particular reason you are using IKEv1? You should just switch to
IKEv2 to avoid any such issues.

Post by Hussaina Begum Nandyala
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?

Post by Hussaina Begum Nandyala
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 Brunner]

Hi Hussaina,

Post by Hussaina Begum Nandyala
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.

I see, you were referring to the SPI in the Notify payload. That's not
relevant here. Let me quote section 3.14 of RFC 2408, which should also

Post by Hussaina Begum Nandyala
How can initiator map this notification payload to any IKE SA without the SPI information ?

SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
therefore, the SPI Size is irrelevant and MAY be from zero (0) to
sixteen (16). If the SPI Size is non-zero, the content of the
SPI field MUST be ignored.

Regards,
Tobias