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
