Hi Tero, To answer the last part of your mail, we always intended address change (and presumably, NAT detection status change) to be supported. This should be clarified in the document, and I have opened Issue #100 for this.
However, given that normal NAT detection happens during IKE_SA_INIT, can you
clarify why this would work better if we had a 2 RT protocol?
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Tuesday, April 21, 2009 14:53
> To: Narayanan, Vidya
> Cc: Yaron Sheffer; Paul Hoffman; IPsecme WG
> Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption
>
> 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
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
