Yaron Sheffer wrote:
Hi Vijay,
I'd rather be consistent with IKE, i.e. send an explicit DELETE.
Ok, I made this change, since there seems to be consensus for an
explicit message when the gateway decides to remove the SA.
Vijay
I suggest to change the -04 text:
Once the client sends an acknowledgement to the gateway, it SHOULD delete
the existing security associations with the old gateway by sending an
Informational message with a DELETE payload. The gateway MAY also decide to
delete the security associations without any signaling from the client.
To:
Once the client sends an acknowledgement to the gateway, it SHOULD delete
the existing security associations with the old gateway by sending an
Informational message with a DELETE payload. The gateway MAY also decide to
delete the security associations without any signaling from the client,
again by sending an Informational message with a DELETE payload.
Thanks,
Yaron
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Vijay Devarapalli
Sent: Saturday, March 07, 2009 1:23
To: Tero Kivinen
Cc: ipsec@ietf.org; pasi.ero...@nokia.com; rfgrave...@gmail.com; Vijay
Devarapalli
Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Tero Kivinen wrote:
Vijay Devarapalli writes:
The draft currently requires the client to delete the SA once it
receives the REDIRECT message from the gateway. I do not want the
gateway to delete the SA right away. The gateway should allow the
client to setup the necessary security associations with the new
gateway before deleting the SA with the existing gateway, if that is
what the client wants to do. The current text is to handle the case
where for some reason the gateway does not receive the DELETE payload
from the client. Note that this shouldn't happen normally. The gateway
garbage collects the SA after a certain time period. I don't think the
gateway needs to send a DELETE payload at this point.
I disagree with that. If gateway decides to delete the IKE SA, it
needs to send DELETE payload in that case. The only case where you do
not send DELETE payload is when you delete the IKE SA because some
exchange over the IKE SA timed out (i.e. other end didn't respond). In
that timeout case there is no point of sending DELETE payload, as most
likely that will not reach the other end any better than the original
exchange, thus it will also timeout.
In this redirect case the client might just be slow, or it might be
that the gateway where client was redirected to does not respond, and
client does not delete the old IKE SA before it gets new one up and
running.
The timeout on the gateway can be quite large. The gateway should give
sufficient time for the client to delete the SA. If the client does not
for some reason, (note that the client is required to delete the SA),
the SAs are just removed. The gateway has already sent a REDIRECT
message to the client. Sending yet another INFORMATIONAL message with
the DELETE payload after a certain time period, is just an overhead, IMHO.
Vijay
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
