[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
[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
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 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
Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
Hello Tero, Thank you for your clear answer. It cleared up my questions. Thanks, Naoyoshi Ueda 2009/9/2 Tero Kivinen : > 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
Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
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 : > 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 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
