|Main Archive Page > Month Archives > ipsec archives|
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.
2009/9/3 Jeff Sun <email@example.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 <firstname.lastname@example.org> 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.
>> > 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
>> 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).
>> IPsec mailing list
> For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation