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 <jsun2...@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 <kivi...@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). >> -- >> kivi...@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
