Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/22/2009 4:11 PM, Tero Kivinen wrote: 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. The 10seconds are not a barometer. So, 1 RT will be closer to the 10ms than the 2 RT, which is better, so I am not sure how you figure it is not noticeable. If someone is in a call, the 2 RT adds to the latency. 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). When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? 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... Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I fail to understand this line of reasoning. What am I missing? thanks, Lakshminath 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? Yes. Both solve the same problem that IKE SA recovers from the IP-address change, or switching from one network to another (i.e. from cellular to WLAN). I do not really see any fundamental reason why the IKE SA needs to be taken down when in cellular. I can see reasons why it might not be needed, but the IKE SA could still be kept up and running, and if done that way, then MOBIKE will offer solution how to move the IKE SA to the new network, and it will mostly do it in 1 RT. Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I am saying we are not sacrificing the user experience in any noticeable way even if we do 2 RT protocol. I expect that 99.999% users will never notice whether the 1 RT or 2 RT protocol was used if there is no attack. On the other hand, 100% users will notice the attacks if 1 RT protocol is used, and 0% of users will notice the attacks if 2 RT protocol is used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/23/2009 3:57 PM, Tero Kivinen wrote: Lakshminath Dondeti writes: When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? Yes. Both solve the same problem that IKE SA recovers from the IP-address change, or switching from one network to another (i.e. from cellular to WLAN). I do not really see any fundamental reason why the IKE SA needs to be taken down when in cellular. I can see reasons why it might not be needed, but the IKE SA could still be kept up and running, and if done that way, then MOBIKE will offer solution how to move the IKE SA to the new network, and it will mostly do it in 1 RT. MOBIKE assumes that the other side has state, correct? Session resumption has to do with providing that state. How are they the same? Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I am saying we are not sacrificing the user experience in any noticeable way even if we do 2 RT protocol. I expect that 99.999% users will never notice whether the 1 RT or 2 RT protocol was used if there is no attack. On the other hand, 100% users will notice the attacks if 1 RT protocol is used, and 0% of users will notice the attacks if 2 RT protocol is used. Under attack, the protocol stretches to 3 RTs. 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? My point is that we'd beyond the real-time budgets after 1 RT anyway. Now of course, to prove any of this (as opposed to your word against mine), we have to workout test scenarios and the like and measure user perception (we can throw in 5 9's all we want, but people spend millions on real perception testing). All I am asking for is for the group to realize that there are cases where the budgets are low and therefore allow the 1 RT exchange. regards, Lakshminath ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
