Lakshminath Dondeti writes: > > I still do not think making the 1 RT protocol to 2 RT protocol in that > > case would really cause any noticeable effect to the actual handover. > > How do you know this?
Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as DHCP delays on WLAN networks. And there is already way to do that in 1 RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of the network or IP-address in 1 RT. Resumption should not really be used for that. Resumption means that something caused the IKEv2 SA in the client to removed, without telling that to the server, and thats why client decided to use resumption instead of just continuing using the IKEv2 SA it has up and running. If we take the network outage example from the charter, the duration of network outage is usually MUCH, MUCH longer than the 2 RTs required to reconnect to the server. > I ask because, I would like to use those arguments to tell people > who are experts in handovers that multiple RTs don't matter. Tell them to use correct protocol on correct places. If they want subsecond recovery from the handover from one network to another, they should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even with MOBIKE it usually takes several seconds for the nodes to actually react that they have lost connectivity, and needs to start corrective actions, but if we assume subsecond recovery is required, then we can also assume the network can immediately tell when recovery actions are required). > Even if this happens, the payoff for the attacker is very little since > the legitimate parties can always establish another connection. No, he does not, as if he was trying to do handover from cellular to WLAN, he would simply continue using cellular in that point, but the accounting for example would be enabled for both (i.e. for servers point of view he is using WLAN and cellular simulatenously, from clients point of view he using only cellular). Again then when he finally gets WLAN which works, he suddenly have 3 RT protocol to use (trying resumption, failing that, and falling back to full IKE) with user authentication, and possibly even user interaction. > The quality of experience would be bad because another session needs > to be established when under attack, but at the cost the attacker > has to pay, one might even say that this is not even a serious > threat. Making the user to do user interaction by simply sniffing one packet from the air, and forwarding it to the right server is very cheap way to annoy people... For users point of view it does not even look he is under attack, he just sees that this crappy network again requires him to reauthenticate at random times. Note, that he does not blame the attacker's network, as he didn't detect anything there. The attack can have happened hours before, and then when he finally comes to the home WLAN network, or some other network which actually works, he sees that he needs to reauthenticate. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec