Subject: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation

From: Matthew Cini Sarreo <[email-masked]>
Date: Tue, 7 Apr 2009 11:51:55 +0200

Hello,

While reading through ikev2 bis 02 (this is most certainly not something new
that surfaced in this document), section 1.4, par 3 states:

"Messages in an INFORMATIONAL exchange contain zero or more Notification,
Delete, and Configuration payloads.  The Recipient of an INFORMATIONAL
exchange request MUST send some response (else the Sender will assume the
message was lost in the network and will retransmit it).  *That response MAY
be a message with no payloads*. The request message in an INFORMATIONAL
exchange MAY also contain no payloads.  This is the expected way an endpoint
can ask the other endpoint to verify that it is alive."

I would like to ask the reason behind this. As "live peer detection" is done
by sending an empty INFORMATIONAL exchange (Encrypted Payload with no
payloads), wouldn't it better to have a response be constructed in such a
way so that the requesting peer can explicitly "know" that this
INFORMATIONAL exchange is a confirmation of the request sent? This way, the
requester would have to parse the response, and not decrypt the message,
discover that there is no payload in the Encrypted Payload, check if the
message is marked as a response and assume it is a confirmation of a
request. Would a message ID be used to check the corresponding request? And
if then the message ID on the responder (to the INFORMATIONAL exchange)
somehow got messed up and does not match what the requester is expecting?

Regards,
Matt

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Apr 2009 13:02:54 +0300

Hi Matt

Requests and responses have matching MsgID numbers. The requestor can instantly identify the response by its matching Msg ID number. INFORMATIONAL exchanges have message authentication codes applied to messages, so the ID numbers can't (or shouldn't) get "messed up" on the responsder.  If it doesn't match, it's an invalid message.
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matthew Cini Sarreo
Sent: Tuesday, April 07, 2009 12:52 PM
To: [email-masked]
Subject: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation

Hello,

While reading through ikev2 bis 02 (this is most certainly not something new that surfaced in this document), section 1.4, par 3 states:

"Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads.  The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will retransmit it).  That response MAY be a message with no payloads. The request message in an INFORMATIONAL exchange MAY also contain no payloads.  This is the expected way an endpoint can ask the other endpoint to verify that it is alive."

I would like to ask the reason behind this. As "live peer detection" is done by sending an empty INFORMATIONAL exchange (Encrypted Payload with no payloads), wouldn't it better to have a response be constructed in such a way so that the requesting peer can explicitly "know" that this INFORMATIONAL exchange is a confirmation of the request sent? This way, the requester would have to parse the response, and not decrypt the message, discover that there is no payload in the Encrypted Payload, check if the message is marked as a response and assume it is a confirmation of a request. Would a message ID be used to check the corresponding request? And if then the message ID on the responder (to the INFORMATIONAL exchange) somehow got messed up and does not match what the requester is expecting?

Regards,
Matt

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Apr 2009 13:27:24 +0300

Matthew Cini Sarreo writes:
> INFORMATIONAL exchange is a confirmation of the request sent?

This is already done. Each request has unique message-id, and each
response will have same message-id, so other end can always tie
correct request and responses togehter.

> This way, the requester would have to parse the response, and not
> decrypt the message, discover that there is no payload in the
> Encrypted Payload, check if the message is marked as a response and
> assume it is a confirmation of a request. Would a message ID be used
> to check the corresponding request?

It is. In the IKEv2 the exchanges are always request-reply pairs,
which are identified by the message-id (which is incremented by 1 for
each exchange). There is separate request-reply pairs in both
directions (separated by the Initiator flag). 

> And if then the message ID on the responder (to the INFORMATIONAL
> exchange) somehow got messed up and does not match what the
> requester is expecting?

If the message id got messed up, the recipient of that message will
throw that message away immediately as it does not fit the message id
window, and it will then wait for the other end to retransmit the
message with correct message id. If the other end has bug causing the
message ids to be messed up in all responses, then the recipient will
time out the exchange, and tear down the whole IKEv2 SA, as the other
end did not reply to its messages.

Note, that IKEv1 handled message id, and exchanges completely
differently waythan what IKEv2 does, so do not assume anything is
staying same from the IKEv1 to IKEv2.
-- 
[email-masked]