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

From: naoyoshi ueda <[email-masked]>
Date: Tue, 1 Sep 2009 17:24:14 +0900

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 2 Sep 2009 15:43:55 +0300

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

Yes.

> even if retransmitted IV differs from that of original request?

Most likely, but it does not matter as the packet will fail window
check, thus will be considered as retransmission or old packet, and
thrown away (it might trigger retransmission of responders reply in
case it was packet in the window).

Note, that this can only happen if the other is non-conforming, or
there is attacker between which modifies the IV. Conforming
implementation will use same IV all time. 

> Just ignore it? Abandon the IKE_SA? Or send some Notify?

If recipient has already seen the message before (i.e it has already
processed it), it can resend its reply. It can also notice that the
packet is not bitwise-same as previously and the message id is old,
and silently ignore it. So this is implementation depended what will
happen. 

If it has not seen the message before, then it does not know the IV
has changed, thus will process the packet normally. 

> Does it need to be identical to the original one too?

The retransmitted response should also be bitwise identical to
original one.

> implicitly requires that. But I'm not sure.

I would agree you that it implicitly requires that.

> and I cannot tell if the behavior is allowed or not.

I would say it is not allowed, but on the other hand, the other end
should not ever notice this, as it only process one of the responses
(the first to reach him), and then ignores rest even before decrypting
them (when it checks its message id). I.e. it ignores further
responses to requests it has already received response.

-- 
[email-masked]

---

From: Jeff Sun <[email-masked]>
Date: Thu, 3 Sep 2009 06:46:58 -0700

All in all, the qualifications of being a true retransmitted IKE
request/response message is dependent on the* post-encrypted* IKE
request/response message being bitwise identical.  Naoyoshi, if you don't
mind me asking, which implementation are observing this behavior from (I'm
not sure if this breaks any rules of engagement of mailing list, so please
respond privately to me if possible)?

- Jeff Sun

On Wed, Sep 2, 2009 at 5:43 AM, Tero Kivinen <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

-- 
For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation

---

From: naoyoshi ueda <[email-masked]>
Date: Fri, 4 Sep 2009 18:32:18 +0900

Hello Tero,

Thank you for your clear answer.
It cleared up my questions.

Thanks,
Naoyoshi Ueda

---

From: naoyoshi ueda <[email-masked]>
Date: Fri, 4 Sep 2009 19:16:23 +0900

Hello Jeff,

Sorry, I withhold the product's name because of my business commitments.

However, I just say that it is not an ordinary network device like VPN gateway.

Regards,
Naoyoshi Ueda

2009/9/3 Jeff Sun <[email-masked]>:
> request/response message is dependent on the post-encrypted IKE