Hi Yaron, We are going back to revisiting consensus here and re-explaining the use cases and I'd certainly like to keep this to as minimum a revisit as possible. The use cases go back to what has been documented in the problem statement we published a while back - draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you should be still able to get to the draft.
As a key point, I'll note that the situation where resumption is used here is a handoff case for a particular client and does not involve all clients connecting at once, where DH could be a problem. And, in these cases, there is no user interaction involved - the mobile devices are doing everything they can to make handoffs seamless and work with no user or even application involvement. If you are only worried about the case of simultaneous reconnection of thousands of nodes, you can feel free to always use the 2-RT method in your gateway implementation - I am pointing out that it is not the universally applicable use case. And, in most cellular deployments, IPsec is used for untrusted access networks (e.g., WLAN), while the DHCP servers and AAA servers are accessible from other access networks as well. And, a handoff from cellular to WLAN needs to be seamless - you can envision an IPsec SA being set up all the time, but only resumed and actively used after you handoff to WLAN. I really don't fancy the "one threat model fits all" solution, since we cannot claim to envision all the use cases that will arise tomorrow, even if we manage to find a way to fit this one model for existing use cases. And, in this case, we can't even fit it for existing use cases - so, let's document the applicable threat model and move forward. Vidya > -----Original Message----- > From: Yaron Sheffer [mailto:yar...@checkpoint.com] > Sent: Monday, April 20, 2009 2:13 PM > To: Narayanan, Vidya; Paul Hoffman; IPsecme WG > Subject: RE: [IPsec] Issue #98: 1 or two round trips for resumption > > [As a coauthor of this draft:] > > Hi Vidya, > > Can you please give a more detailed description of this use case, > where: > > - The gateway doesn't care about CPU consumption, to the extent where > it > doesn't mind the extra DH+RSA operations for thousands of > simultaneously > arriving clients, and, > - The number of round trips until something useful happens (e.g. user > interaction) is so low that our 1 extra RT becomes critical. > > Thanks, > Yaron > > > -----Original Message----- > > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On > Behalf Of > > Narayanan, Vidya > > Sent: Monday, April 20, 2009 22:52 > > To: Paul Hoffman; IPsecme WG > > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > > > Considering that I didn't know what "now" meant and this message > didn't > > have a deadline, I hope my input is considered. I prefer the first > option > > - we need to document the associated threat model with each > assumption, > > but, deployments need to figure out what their threat model is. The > one > > RT resumption mechanism is key for handoff situations and for certain > > environments, it doesn't allow new attacks that are feasible outside > of > > the IPsec use anyway. If we threw out this model, we will be > preventing a > > whole class of use cases that could otherwise use this resumption > > mechanism. > > > > Note that for these use cases, it is not much more expensive to just > do > > the DH and use regular IKEv2, instead of using resumption, if the > latter > > also involved as many roundtrips. > > > > Thanks, > > Vidya > > > > > -----Original Message----- > > > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On > Behalf > > > Of Paul Hoffman > > > Sent: Wednesday, April 08, 2009 10:56 AM > > > To: IPsecme WG > > > Subject: [IPsec] Issue #98: 1 or two round trips for resumption > > > > > > Greetings again. Tracker issue #98 is the same as the message that > Pasi > > > sent to the mailing list last month; see <http://www.ietf.org/mail- > > > archive/web/ipsec/current/msg04050.html>. There is disagreement > among > > > the authors of the session resumption draft how to deal with this > > > issue. > > > > > > One proposal is to add text similar to Pasi's to the document in > order > > > to let implementers understand all the things that they might need > to > > > do to prevent damage from a replay attack. If this is the method > > > chosen, it should probably be as a section in the main body of the > > > document, not as a "security consideration" because the issues are > more > > > operational than security. > > > > > > A different proposal is to get rid of the one-round-trip mode and > have > > > the protocol always take two round trips. This prevents the attack > that > > > Pasi brings up, at a higher cost for the clients and server. > > > > > > If you have a preference between these two proposal, please state > it > > > now. > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
