Sorry, it doesn't work for me. For a few reasons: - EAP authentication is the primary use case I see for the Redirect mechanism. If anything should be solved well, it's EAP authentication. - The proposal introduces Redirect during IKE_AUTH, which is fine, but then it reintroduces the complexity of a post-IKE_AUTH Informational. So what's the benefit? Why not simply define that Redirect can always be sent as part of the last message of IKE_AUTH, no matter what was the authentication method. - And lastly, I think the empty response following the IKE_AUTH response is redundant. You don't need to acknowledge a response.
Thanks,
Yaron
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email protected]]
> Sent: Wednesday, March 18, 2009 20:32
> To: Tero Kivinen; Yaron Sheffer; [email protected];
> [email protected]
> 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
>
>
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
