Tero Kivinen wrote:
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.
Thats an oversight. I combined the IKE_AUTH response with
NO_ADDITIONAL_SAs payload and the Informational message with REDIRECT
payload, but didn't remove the ack from the client. This is fixed now.
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.
The IKEv2 of course succeeded, otherwise the IKE_AUTH exchange would not
have happened. The client needs to delete the IKEv2 SA after receiving
the REDIRECT 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.
I think we should keep this simple, assume that the IKEv2 SA does not
become invalid because of the REDIRECT message received during the
IKE_AUTH exchange and have the client delete the IKEv2 SA.
If the REDIRECT is received during the IKE_SA_INIT exchange, then the
IKEv2 SA is not created.
This is what is described in the document currently.
Vijay
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).
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
