Hi Hui, Thank you for your comments. Regarding your second comment, please see http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-resumption-08#section-9.4 Regards, Yaron > -----Original Message----- > From: Hui Deng [mailto:denghui02@xxxxxxxxx] > Sent: Tuesday, September 22, 2009 17:40 > To: Tero Kivinen > Cc: Yaron Sheffer; IPsecme WG; ietf@xxxxxxxx; Peny Yang > Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption > (IKEv2 Session Resumption) to Proposed Standard > > Comments inline, thanks > > 2009/9/3 Tero Kivinen <kivinen@xxxxxx>: > > 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). > [Hui] I don't think so. IMO, in the list, the comparison of extended > IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus > yet. > It was a ballot in the mailing list in the begining, and it is quite > clear more people opposing > sepaparate exchange, we could do one more round ballot if needed. > > > > >> > 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. > > [Hui] I also agree with Peny and Tero. Although way of detecting > failure of gateways is out of the scope of current charter, WG draft > should at least handle the issues incurred by mis-judgement of client. > > thanks > > -Hui > > Scanned by Check Point Total Security Gateway. Email secured by Check Point Email secured by Check Point _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf