My feel is that REDIRECT in response to IKE_SA_INIT, first response of IKE_AUTH phase (4th message) and Gateway initiated REDIRECT are good enough If there is a need for REDIRECT after EAP, then I would think that it is more required along with EAP_SUCCESS than at the end. If there are two EAP authentication stages, there may be a requirement to redirect the Initiator to some other VPN Router based on result from first EAP authentication. So, my suggestion in regards to EAP is to send the REDIRECT to Initiator along with EAP-SUCCESS payload.
Thanks Srini -----Original Message----- From: Vijay Devarapalli [mailto:[email protected]] Sent: Wednesday, March 18, 2009 11:32 AM To: Tero Kivinen; Yaron Sheffer; [email protected]; Addepalli Srini-B22160 Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Tero Kivinen wrote: > Vijay Devarapalli writes: >> My proposal is to limit the REDIRECT payload to appear in message #4 (in >> the first IKE_AUTH response), based on the identity presented by the >> client. And leave EAP scenarios out of scope for this document. > > If others feel this is needed, I am willing to accept that solution, > as it should still be fixed defined location, which means testing it > will be simplier. > >> If someone wants the AAA server to redirect the client based on the >> EAP exchange, a separate document could be written. And this >> document can specify that the REDIRECT message can be sent in >> message 10. > > In this case I would rather propose doing the IKE AUTH exchange > completely and then using the INFORMATIONAL exchange to redirect the > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the > first response IKE_AUTH packet of the exchage, and nowhere else. Agree. Here is the text proposal to address this issue. If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the IKE_AUTH request message, it prevents the creation of a CHILD SA and sends the REDIRECT payload in the IKE_AUTH response. When the client receives the IKE_AUTH response with the REDIRECT payload, it MUST send an empty message as an acknowledgement and delete the IKEv2 SA as described above. Initiator Responder ( VPN GW) --------- ------------------- (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_SUPPORTED) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> In case the IKE_AUTH exchange involves EAP authentication as described in Section 2.16 of RFC 4306 [2] or multiple authentication methods as described in RFC 4739 [6], the IKE_AUTH exchange is more complicated. The identity presented by the client in the first IKE_AUTH request might be a temporary one. In addition, the gateway might decide to redirect the client based on the interaction with the the AAA server, when EAP authentication is used or the external authentication server, when multiple authentication methods are used. In such cases, the gateway MUST complete the IKE_AUTH exchange and then use the gateway-initiated redirect mechanism, i.e., an INFORMATIONAL message with the REDIRECT payload, to redirect the client to another gateway. Pasi, Yaron, Srini, does the above work for you? Vijay _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
