Subject: [IPsec] IKEv2 INVALID_MESSAGE_ID

From: Matthew Cini Sarreo <[email-masked]>
Date: Mon, 20 Apr 2009 09:09:50 +0200

If an implementation decides to send the INVALID_MESSAGE_ID
notification, shoild it ONLY send this after an IKE_AUTH exchange has
been completed? It seems to be so as section 2.3 states that an
INFORMATIONAL exchange is started, but it is not clear what should be
done if a message of the two initial exchanges has an invalid message
id (an implementation should always use 0 for IKE_SA_INIT and 1 for
IKE_AUTH, but what if this does not happen?)

Regards,
Matt

---

From: Yoav Nir <[email-masked]>
Date: Mon, 20 Apr 2009 10:48:25 +0300

Hi Matt.

You can't initiate INFORMATIONAL exchanges before the IKE_AUTH exchange(s) concluded successfully. 

Section 2.3 prohibits sending INVALID_MESSAGE_ID in responses, so you don't use that for the IKE_AUTH exchange.

If the IKE_AUTH exchange contains invalid message IDs, these requests MUST be ignored. I don't think you ever begin to use the message window until after the IKE_AUTH exchange, and INVALID_MESSAGE_ID is not some kind of MALFORMED_PACKET. It's specifically to tell the other side about window problems.

Hope this helps

Yoav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Matthew Cini Sarreo
> Sent: Monday, April 20, 2009 10:10 AM
> To: [email-masked]
> Subject: [IPsec] IKEv2 INVALID_MESSAGE_ID
> 
> notification, shoild it ONLY send this after an IKE_AUTH 
> exchange has been completed? It seems to be so as section 2.3 
> states that an INFORMATIONAL exchange is started, but it is 
> not clear what should be done if a message of the two initial 
> exchanges has an invalid message id (an implementation should 
> always use 0 for IKE_SA_INIT and 1 for IKE_AUTH, but what if 
> this does not happen?)
> 

Email secured by Check Point

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Tue, 21 Apr 2009 17:30:46 +0530

Hi,

Please validate if the following is true.

Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM,
TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE,
DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads.

Like if we get packet as HDR, SA1, SA1, KE, N
We should reject it ?

Regards,
kalyani

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Apr 2009 16:49:17 +0300

> DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads.

Encrypt MUST be last packet, thus that also limits that there can be
only one of such payloads in packet.

For all others there is no explicit restriction that they cannot
appear multiple times, but on the other hand the exchanges we now have
do not ever put multiple SA, KE, IDi, IDr, AUTH, Ni/Nr (Nonce), TSi,
TSr, or EAP payloads in the same packet.

For CERT, CERTREQ, N (notify), D (delete), V (Vendor ID) it is clear
that there CAN be multiple payloads of those types in same packet.

For CP (configuration payload) it not clear whether there can be
multiple or not, but I would expect most implementations expect to
find only one, and will only use one.

In future someone might make extensions which puts multiple CP
payloads in same packet, but currently we do not have such.

> Like if we get packet as HDR, SA1, SA1, KE, N

Best would be to check first the exchange type, and check out that all
mandatory payloads which are required for that are there. Also when
parsing it should be quite ok to stop parsing immediately when you see
for example 2nd encrypted payload, or 2nd SA payload (In IKEv1 we
could have multiple SA payloads in one quick mode exchange, as there
was option to create multiple IPsec SAs at once, but that is not
allowed in IKEv2). After that parsing all optional payloads (notifies,
vendor id payloads, etc).

Then the question is whether there is any need to check if there is
any extra payloads in the exchange, and if such is found what to do
(lets say someone puts configuration payload as part of the
IKE_SA_INIT instead of IKE_AUTH). For this there is no clear answer,
if you want to be able to work with future extensions without breaking
when seeing them, best might be just ignore them.
-- 
[email-masked]