Hi Tero,
We are thinking of different use cases.
You are thinking VPN client - VPN server (and similar client/server cases). I
agree that client-side redirect is useless in this case. MOBIKE takes care very
well of the multihomed case (one address on WLAN, another on GPRS). So I don't
care if the current draft doesn't work for that case.
I am thinking of symmetric IKE peers (gateways, or endpoints using transport
mode ESP; no EAP, rarely any NAT). Is there any reason why the current draft
cannot support this case in a symmetric manner?
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Friday, March 06, 2009 15:52
> To: Yaron Sheffer
> Cc: Vijay Devarapalli; pasi.ero...@nokia.com; ipsec@ietf.org;
> rfgrave...@gmail.com
> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
>
> Yaron Sheffer writes:
> > I have a slight preference to keeping the protocol symmetric. But
> > even if we choose not to do that, I think Tero's text (quoted below)
> > leaves too much room for interpretation.
>
> Redirect is not really symmetric ever. If it would be used in
> symmetric way, then each end would simply create the connection using
> the address they want whenever they want. I.e. if server wanted to
> redirect client to somewhere else later, it would simply inform that
> new gateway to make connection to the client and close the local
> connection. That new gateway would then simply initiate new connection
> to the client and move traffic to there.
>
> The reason we cannot do that is that client-server connections are
> very often asymmetric, i.e. we are using EAP, or client is behind NAT
> or similar problems.
>
> > 7. Use of the Redirect Mechanism between IKEv2 Peers
> >
> > The Re-direct mechanism described in this document is mainly intended
> > for use in client-gateway scenarios. However, the mechanism can also
> > be used between any two IKEv2 peers, but this protocol is
> > asymmetric, meaning that only the responder can redirect initiator
> > to some other server.
> > ---
> >
> > The protocol supports using an Informational exchange for redirect
> > at any time during the SA lifetime, and this is inherently
> > symmetric.
>
> No, it does not make it symmetric. If the original initiator wants to
> use other local address when connecting, he will simply switch to that
> new address and initiate new connection. Original responder cannot do
> that, as most likely the connection using new address does not work
> because of NATs or because of asymmetric authentication type used
> (EAP).
>
> > And of course, following an IKE SA rekey, the
> > initiator/responder roles might change. If we go for the restricted
> > option, the new text should cover both of these issues.
>
> I should have used "original responder" and "original initiator".
> --
> kivi...@iki.fi
>
> Scanned by Check Point Total Security Gateway.
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
