Vijay Devarapalli writes: > Agree. Here is the text proposal to address this issue. > > If the gateway decides to redirect the client during the IKE_AUTH > exchange, based on the identity presented by the client in the > IKE_AUTH request message, it prevents the creation of a CHILD SA and > sends the REDIRECT payload in the IKE_AUTH response. When the client > receives the IKE_AUTH response with the REDIRECT payload, it MUST > send an empty message as an acknowledgement and delete the IKEv2 SA > as described above.
That empty message as an acknowledgement is completely against the generic IKEv2 exchange model. That is unacceptable. Also the text does not say whether the IKE SA creation succeded or failed when REDIRECT was sent. As REDIRECT is status notification it would indicate that IKE SA succeded, and in your example it must have succeeded, as initiator used it after the IKE_AUTH to send that empty message. I think the correct way to do that is to split REDIRECT to two different notifications, one REDIRECT that is allocated from the NOTIFY MESSAGES - ERROR TYPES range (0-8191) which indicates that the IKE SA creation failed and initiator MUST move to new location. This is the one that should be used in the IKE_SA_INIT and IKE_AUTH phase. Then there would be another status REDIRECT, which is allocated from the NOTIFY MESSAGES - STATUS TYPES. This status REDIRECT would be used in the INFORMATIONAL exchanges, i.e. where it does not cause IKE SA to be deleted when such notify message is received. This whole discussion is putting more and more me back to my original opinion that we should NOT allow redirects during IKE_AUTH. There is reason to do the redirect during IKE_SA_INIT before doing Diffie-Hellman. There is reason to do it after kwowing the identity, but as others has pointed out in that case it should be done only after the identity has been proven. If redirection is done only after identity has been proven, then it can be done as separate INFORMATIONAL exchange after the IKE_AUTH. I do not want REDIRECT to be defined so that it can be sent any time during IKE_AUTH as that exponentially multiple the number of test cases required for IKE_AUTH tests (i.e. test REDIRECT during all the possible half a dozen messages using different authentication methods including multiple authentication etc). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
