Hi Team, I agree with Pasi.
Regards, Raj On Fri, Jun 5, 2009 at 5:12 PM, <[email protected]> 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? > > 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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
