Yaron Sheffer writes: > [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in > fact an early version of our work did exactly that. But the working group > gave us a clear direction to use a separate exchange, and this is where we > disagree: I believe we did have a strong WG consensus that the > implementation benefits of having a separate exchange (i.e. not overloading > even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the > alternative. I agree on that (both to the WG having consensus and also that using separate exchange is better). > > I know that how a client detects the need for resumption is out of the > > scope of this draft. But, there is the possibility that IPsec client > > may be continuously deceived and believe the fail of IPsec gateway. It > > may continuously present the ticket and update the ticket. In this > > sense, IMHO, this draft should take care of this case. > > > [YS] If I understand the scenario correctly, it is similar to an attacker > repeatedly sending notifications to an IKE client, making it believe that > the IKE exchange has failed and needs to be reinitiated. This attack against > plain-vanilla IKE would be much more CPU-intensive to the client and to the > (real) gateway, compared to repeated session resumption. Even when you > factor in the cost of generating a new ticket. Moreover, the regular IKEv2 > anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. Regardless what notifications or ICMP messages you send to any of the IKE end points that MUST NOT cause them to consider IKE SA failed. It "MUST conclude that the other endpoind has failed only when repeated attemtps to contact it have gone unanswered for timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity." (RFC 4306 section 2.4) Notifications and ICMP messages may trigger other end to send empty INFORMATIONAL message to check whether the other end is alive or not and only if that times out then the other end is considered dead. This means this kind of attack is not possible with notifications and ICMP. On the other hand I do agree with Peny that, as resumption draft makes it out of scope for this draft, how a client detects the need of resumption, we might need more text explaining this attack. I.e. we might need to add text to security considerations which says that the client implementations should not trust any untrusted source when they are trying to detect whether the resumption is needed. -- kivinen@xxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf