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
