Narayanan, Vidya writes:
> Hi Yaron,
> We are going back to revisiting consensus here and re-explaining the
> use cases and I'd certainly like to keep this to as minimum a
> revisit as possible. The use cases go back to what has been
> documented in the problem statement we published a while back -
> draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you
> should be still able to get to the draft.
>From the ipsecme charter:
Failover from one gateway to another, mechanisms for detecting
when a session should be resumed, and specifying communication
mechanisms between gateways are beyond the scope of this work
item.
Thus failover from one gateway to another is outside the scope of this
document. If I remember right most of the use cases in
draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not
resumption use cases.
> As a key point, I'll note that the situation where resumption is
> used here is a handoff case for a particular client and does not
> involve all clients connecting at once, where DH could be a problem.
> And, in these cases, there is no user interaction involved - the
> mobile devices are doing everything they can to make handoffs
> seamless and work with no user or even application involvement.
>
> If you are only worried about the case of simultaneous reconnection
> of thousands of nodes, you can feel free to always use the 2-RT
> method in your gateway implementation - I am pointing out that it is
> not the universally applicable use case.
>From the abstract of the resumption document:
To re-establish security associations (SAs) upon a failure recovery
condition is time consuming especially when an IPsec peer (such as a
VPN gateway) needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.
So at least it was seen as important use case, and is thats why
included in the abstract (and the ipsecme charter text).
> And, in most cellular deployments, IPsec is used for untrusted
> access networks (e.g., WLAN), while the DHCP servers and AAA servers
> are accessible from other access networks as well. And, a handoff
> from cellular to WLAN needs to be seamless - you can envision an
> IPsec SA being set up all the time, but only resumed and actively
> used after you handoff to WLAN.
Hmm.. This is again something completely different what I tought for
what the resumption protocol is supposed for. For example for this use
it would be useful to have have some way to force deletion of the
state from the server, i.e. say that this IKE SA is now going to go to
sleep, so you can remove the state, and there is no need to do dead
peer detection on it. The current protocol do not have anything like
that, and if you delete IKE SA you also delete the ticket, so that
mechanism cannot be used for that.
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.
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
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.
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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
