Somehow, we in the IETF think that we can make decisions for other standards bodies, especially ones that do real deployments. I don't know how we can say things like they should always use the IKE SA whether they need it or not - there can be several reasons not to use it when they don't need it, including how some VPN vendors may charge. Also, mobility may need to be handled by MIP6 and we know that it doesn't co-exist with MOBIKE.
I'm also further intrigued by this attack we are so passionately discussing - the motivation for the attacker here is to annoy other users? Surely, the attacker gets nothing meaningful in return - I simply can't see how the risk of such an attack can be anywhere close to even medium - it is barely low in my view. The reward for the attacker in return for the work is non-existent - if someone can steal spectrum or otherwise get Internet access for free or get access to other users' credentials, etc., it is worth discussing and protecting against. In this case, I'd say that we've already spent more time discussing it than it is worth it. Vidya > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Tero Kivinen > Sent: Thursday, April 23, 2009 6:50 AM > To: Dondeti, Lakshminath > Cc: IPsecme WG; Paul Hoffman > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > Lakshminath Dondeti writes: > > MOBIKE assumes that the other side has state, correct? > > Yes. > > > Session resumption has to do with providing that state. How are they > > the same? > > In this example given (handover from cellular to wlan, without > breaking existing phone call), I do not really see any point why the > IKE SA state needs to be removed from the server side, and as such I > think the much better solution is to use MOBIKE and keep IKE SA up all > the time. > > As I do not have any idea where people want to use the resumption, I > have VERY HARD time to justify the different protocol options. But > anyways one of the things required is that it "shall not have negative > impact on IKEv2 security features", and I think 1 RT protocol will > have negative impact to security features. > > > Under attack, the protocol stretches to 3 RTs. > > 3 RT + Diffie-Hellman + public key operation + user interaction to > type in password or securid token etc. > > > So, you are saying that there is no noticeable difference between 1 > > and 2 RTs, but there is between 2 and 3? Is your point that the DH > > computation will be noticed? > > With group 18: yes... With typing in the passphase to do > reauthentication with RSA token card : yes. With digging out your > securid card and typing in pin, and typing in the next token to the > prompt: yes. > > > My point is that we'd beyond the real-time budgets after 1 RT > > anyway. > > You should not really do break-before-make style of transitions on > real-time environments, and if you keep the old connection while > making the new one, then this whole issue is non-issue. > -- > kivi...@iki.fi > _______________________________________________ > 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
