Hi Vijay, I don't have the details at hand, but in 3GPP land it is common for the client to send all sorts of temporary identities, and for the AAA server to respond to the Packet Data Gateway (that's our gateway) with the client's "true" identity (IMSI, MSISDN, whatever). Such permanent identity could serve as the basis for a redirect decision. Do we have people on the list familiar with these specs?
Thanks,
Yaron
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email protected]]
> Sent: Tuesday, March 17, 2009 0:12
> To: Yaron Sheffer; Tero Kivinen
> Cc: IPsecme WG
> Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-
> ietf-ipsecme-ikev2-redirect-04)
>
> Hi Yaron, Tero,
>
> We don't really have a protocol extension (EAP, RADIUS or Diameter) for
> the AAA server to tell the IKEv2 gateway to redirect the client to
> another gateway.
>
> In addition, if there is an EAP exchange, the true identity of the
> client is not revealed to the gateway.
>
> So I am not sure on what basis the gateway would redirect the client in
> message #10 and #18 in Tero's email.
> http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html
>
> 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
> 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.
>
> Does this sound good?
>
> Vijay
>
> On Thu, 2009-03-12 at 16:07 -0400, Yaron Sheffer wrote:
> > We should not do the redirect based on an asserted, unautheticated
> identity.
> > Going back to Tero's previous message on this thread, I think we should
> > allow redirect both in message 10 and 18 (i.e. following both EAP
> rounds,
> > and where the EAP state machine is "idle"). The gateway probably needs
> the
> > AAA server to tell it where to redirect to, anyway.
> >
> > In message 10 the gateway still doesn't know that the client wants to
> > perform secondary authentication, but I propose to ignore this issue for
> > simplicity.
> >
> > Thanks,
> > Yaron
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] On Behalf
> Of
> > > Tero Kivinen
> > > Sent: Thursday, March 12, 2009 14:15
> > > To: Vijay Devarapalli
> > > Cc: IPsecme WG; Yoav Nir; [email protected]
> > > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:
> > > draft-ietf-ipsecme-ikev2-redirect-04)
> > >
> > > Vijay Devarapalli writes:
> > > > The one significant piece of information that the gateway has during
> the
> > > > IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT
> exchange,
> > > > is the identity of the client. Some folks want to redirect the
> client
> > > > based on whatever identity it presents. So if thats they case, the
> first
> > > > IKE_AUTH response would be used for sending the REDIRECT payload. If
> the
> > > > gateway wanted to redirect the client because of load conditions, it
> > > > would have done it during the IKE_SA_INIT exchange itself. I don't
> > > > expect the EAP exchange or the multiple auth exchange to trigger a
> > > > redirect. We can make this explicit if needed.
> > >
> > > I tought someone wanted to do some kind of radius lookup to select
> > > where client is redirected to and in some cases client might not be
> > > sending the ID used for that in the ID payload but might use the EAP
> > > identity request/reply (even though RFC4306 3.16 says SHOULD NOT).
> > >
> > > If it will be enough to only see IDi to do redirect, meaning we can
> > > always restrict the REDIRECT to message 4, then it might be even
> > > acceptable to make that change. The main reason I was against having
> > > REDIRECTS in IKE_AUTHs is that there is so many locations where it can
> > > be and testing all possible combinations with all possible
> > > authentication methods and other extensions gets very complicated.
> > > --
> > > [email protected]
> > > _______________________________________________
> > > IPsec mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> > > Scanned by Check Point Total Security Gateway.
> > >
> > > Scanned by Check Point Total Security Gateway.
>
> 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
