On 4/21/2009 5:23 PM, Tero Kivinen wrote:
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.
Hi Tero,
How do you know this? I ask because, I would like to use those
arguments to tell people who are experts in handovers that multiple RTs
don't matter.
Especially as you still most likely have the cellular network there to
be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the
WLAN, thus only thing that is affected is that traffic moves 100ms
later from cellular to WLAN.
On the other hand security problems are big issue, as you most likely
How do we know that they are a "big" issue? Do we expect these systems
to be under attack most of their operational life?
try to IKE_SESSION_RESUME exchange over any WLAN you happen to see,
thus you effectively broadcast your tickets to attackers at will, so
attackers can simply take those tickets and sent them to server and
get your session resumed, but not forward any other traffic. Also any
firewall allowing port 500 packets out but not in, will cause similar
effect, as you will not get reply back, but server will consume your
ticket.
Even if this happens, the payoff for the attacker is very little since
the legitimate parties can always establish another connection. 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.
I really would liked to be convinced that I am wrong here, but I see
this to be a quite moderate or low risk attack.
thanks,
Lakshminath
That case also brings out completely new issue which has not been
discussed before, i.e. whether the IKE_SESSION_RESUME must come from
the same IP-address than what was used before for the IKE SA, i.e. can
the IP-addresses change during the IKE_SESSION_RESUME. If that is
allowed, then what about NATs, i.e. is it allowed that even when there
was no NAT between hosts before, there is new NAT found during the
IKE_SESSION_RESUME?
Those are not covered by the current document, and at least something
MUST be said about those issues.
After this example use scenario, I am even more convinced that 2 RT
protocol is better and needed, especially if we do allow IP-addresses
change, and might need to do NAT-T detection on the IKE_SESSION_RESUME
exchange too. Allowing IP-addresses change means that the network
where the packets can come in, are different, meaning they might have
misconfigured firewalls or similars there, and killing your resumption
ticket by just trying to connect through broken firewall is bad idea.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
