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? AFAIK, the current text is *not* supposed to allow that -- but it seems it is indeed quite unclear. Best regards, Pasi _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
