ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted

[IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets

From: naoyoshi ueda <piyomaru3141_at_nospam>
Date: Tue Sep 01 2009 - 08:24:14 GMT
To: ipsec@ietf.org

Hi All,

I have a question about IVs of retransmitted packets.

According to ikev2bis-04 section 2.1:
> A retransmission from the initiator
> MUST be bitwise identical to the original request. That is,
> everything starting from the IKE Header (the IKE SA Initiator's SPI
> onwards) must be bitwise identical; items before it (such as the IP
> and UDP headers, and the zero non-ESP marker) do not have to be
> identical.

So, IV of retransmitted request must be the same as that of original request.

Meanwhile, ikev2bis-04 section 3.14 says
> o Initialization Vector - For CBC mode ciphers, the length of the
> initialization vector (IV) is equal to the block length of the
> underlying encryption algorithm. Senders MUST select a new
> unpredictable IV for every message; recipients MUST accept any
> value.

Question 1:
Does the statement "recipients MUST accept any value." stay true even if retransmitted IV differs from that of original request?

Question 2:
If the answer to Question 1 is no, what should the recipient do? Just ignore it? Abandon the IKE_SA? Or send some Notify?

Question 3:
How about IV of retransmitted RESPONSE?
Does it need to be identical to the original one too? It seems to me that the following statement in section 2.1 implicitly requires that. But I'm not sure. Actually, I'm now involved in a IKEv2 implementation that sends retransmitted response with different IV from original one and I cannot tell if the behavior is allowed or not.

ikev2bis-04 section 2.1:
> The responder MUST remember each
> response until it receives a request whose sequence number is larger
> than or equal to the sequence number in the response plus its window
> size (see Section 2.3).

Thanks in advance,
Naoyoshi Ueda

IPsec mailing list