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

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

From: naoyoshi ueda <piyomaru3141_at_nospam>
Date: Fri Sep 04 2009 - 09:32:18 GMT
To: Tero Kivinen <kivinen@iki.fi>


Hello Tero,

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

Thanks,
Naoyoshi Ueda

2009/9/2 Tero Kivinen <kivinen@iki.fi>:
> naoyoshi ueda writes:
>> 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.
>
> Yes.
>
>> 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?
>
> 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.
>
>> 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?
>
> 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.
>
>> Question 3:
>> How about IV of retransmitted RESPONSE?
>> Does it need to be identical to the original one too?
>
> The retransmitted response should also be bitwise identical to
> original one.
>
>> It seems to me that the following statement in section 2.1
>> implicitly requires that. But I'm not sure.
>
> I would agree you that it implicitly requires that.
>
>> 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.
>
> 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.
>
>> 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).
> --
> kivinen@iki.fi
>



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec