Vijay Devarapalli wrote: > > 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.
This is exactly the opposite of my assumption so far, so clearly the draft needs to be clarified one way or another. Anyone else in the WG care to comment? If the gateway sends REDIRECT in the last IKE_AUTH response, can the client ignore it and continue using the IKE_SA? (REDIRECT during IKE_SA_INIT clearly cannot be ignored by the client; at least, it cannot continue the IKE negotiation.) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
