Hi Pasi, On 6/5/09 4:42 AM, "pasi.ero...@nokia.com" wrote:
> Vijay Devarapalli wrote: > >>> And having these two cases is more complex than having just one >>> (IKE_SA is not used for any more exchanges). What benefits does >>> this additional complexity (both in spec and in implementation) >>> get us? >>> >>> If nothing, let's just remove it.... >> >> When the AUTH payloads are exchanged and verified, the IKEv2 SA is >> valid. This seems straightforward. We are not doing anything out of >> the ordinary here by not invalidating the IKEv2 SA just because the >> gateway sent the REDIRECT payload to the client. >> >> I can imagine extensions tomorrow that would let the client convey >> additional information using the IKEv2 SA to the gateway, after the >> gateway had sent a REDIRECT payload to the client. > > What do you mean by "valid"? So the client could potentially ignore > the redirect (in the last IKE_AUTH response), and continue using the > IKE_SA (at least for some time) for other exhanges? Yes, the client can use the IKEv2 SA for other exchanges if it wants to. When the AUTH payloads have been exchanged and verified, the IKEv2 SA setup is complete, IMO. I don't think the REDIRECT payload during the IKE_AUTH exchange should invalidate the IKEv2 SA. So the IKEv2 SA needs to be explicitly torn down. > AFAIK, the current text is *not* supposed to allow that -- but > it seems it is indeed quite unclear. The current text only says the client SHOULD delete the IKEv2 SA with an Informational message if it receives a REDIRECT payload in the IKE_AUTH response. Only when EAP is used and the gateway decides to redirect based on an unauthenticated ID, is the IKEv2 SA not created. The client does not have to send a message to delete the IKEv2 SA in this case. At least this has been my assumption so far. Vijay > > Best regards, > Pasi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
