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 - 10:16:23 GMT
To: Jeff Sun <jsun2501@gmail.com>


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 <jsun2501@gmail.com>:
> 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 <kivinen@iki.fi> wrote:
>>
>> 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
>
>
>
> --
> For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation
>



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