[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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
