Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
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
[IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
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
[IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
