Subject: [IPsec] Redirect draft and REDIRECT_ACK notify

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Dec 2008 12:49:42 +0200

What is the meaning of the REDIRECT_ACK notify?

In IKEv2, we normally just send empty reply back to indicate we have
received the message, unless there is some information we need to send
back. As we have separate REDIRECT_ACK in redirect draft that would
indicate for me that following exchange is valid:

----------------------------------------------------------------------
       Initiator (VPN client)        Responder (VPN GW)
       ----------------------        ------------------

                               <--  HDR, SK {N[REDIRECT, IP_R/FQDN_R]}

     HDR, SK {} -->

		I.e. the client simply replies with empty reply which
		means it rejected the redirect now, then when it is
		ready to do redirect it will send:

     HDR, SK {N[REDIRECT_ACK]} -->

		and server will send normal empty reply to that:

			       <-- HDR, SK {}

		And then client will delete the SA as specified in the
		spec:

     HDR, SK {D} -->

		And server will ack that delete request with empty
		reply as normally:

			       <-- HDR, SK {}

		And then the IKE SA has been deleted.
----------------------------------------------------------------------

I do not think we want to support such behavior, in which case it
would be better to get rid of the REDIRECT_ACK completely, i.e. do the
following exchange instead:

----------------------------------------------------------------------
       Initiator (VPN client)        Responder (VPN GW)
       ----------------------        ------------------

                               <--  HDR, SK {N[REDIRECT, IP_R/FQDN_R]}

     HDR, SK {} -->

		After this the server knows client has received the
		redirect request, and as client does not have option
		to reject it, the reply to the request means that
		client is ready. Then client will delete the SA as
		normally when it is ready:

     HDR, SK {D} -->

		And server will ack that delete request with empty
		reply as normally:

			       <-- HDR, SK {}

		And then the IKE SA has been deleted.
----------------------------------------------------------------------

The draft is not very clear about who deletes the IKE SA, it just says
that client "SHOULD delete the existing security associations with the
old gateway.", but it also says that "The gateway MAY also decide to
delete the security associations without any signaling from the
client.".

As in IKEv2 all deletation of SAs will be done explicitly with delete
notifications that means that client SHOULD send them out, but server
MAY also delete the IKE SA if client does not delete it on time. It
would be better to explictly mention those delete payloads sent by the
client.

So my suggestion is to remove the whole REDIRECT_ACK as it is not
needed, and just adds one more complication to the protocol (i.e.
allows client to delay the redirection for long time by not replying
with the REDIRECT_ACK directly but only after some time (the draft
says it MUST send INFORMATIONAL message with REDIRECT_ACK but it does
not say when).

Also the description of re-transmisions is bit odd as that is normal
IKEv2 behavior for request and reply.

And I also suggest adding explicit text saying client sends delete
payloads when it is ready to delete the IKE SA.

I.e. change section 5 to:
----------------------------------------------------------------------
5.  Gateway Initiated Redirect

   The re-direct mechanism may also be used by a VPN gateway to re-
   direct the client to another VPN gateway in middle of a session. To
   re-direct a client, the gateway should send an INFORMATIONAL
   message with the REDIRECT Notify payload. The REDIRECT payload MUST
   carry information about the new VPN gateway. When the client
   receives this message, it acknowledge it with empty reply (as by
   normal IKEv2 rules). After the client has acknowledged the message
   it should delete the old IKE SA (send delete payload as separate
   INFORMATIONAL exchange and server replies to that with empty reply)
   when it is no longer needed.

   The following illustrates the INFORMATIONAL message exchange for
   gateway- initiated redirect.

       Initiator (VPN client)        Responder (VPN GW)
       ----------------------        ------------------

                               <--  HDR, SK {N[REDIRECT, IP_R/FQDN_R]}

     HDR, SK {} -->

		Client redirects, and when it does not need old IKE SA
		any more it will delete it:

     HDR, SK {D} -->

                               <--  HDR, SK {}

   The INFORMATIONAL message exchange described above is protected by
   the existing IKEv2 SA between the client and the gateway.

   The gateway MAY also decide to delete the IKE SA (by sending normal
   delete payload as INFORMATIONAL exchange) without any signaling
   from the client. However, it should allow sufficient time for the
   client to setup the required security associations with the new
   security gateway. This time period should be configurable on the
   gateway.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 19 Dec 2008 16:34:41 +0200

Hi Tero, Vijay,

If we remove the explicit REDIRECT_ACK, I suggest that we mandate
REDIRECT_SUPPORTED to be sent by both peers in IKE_SA_INIT, unless the
response already has another REDIRECT-related notification (the current
draft has only the client sending REDIRECT_SUPPORTED). Otherwise the
recipient of an empty acknowledgement may not know whether the other side
understood the notify.

I realize the draft is asymmetric, and this may not be necessary for the
exchanges we have in the current version. But we may end up using it in
gateway-to-gateway situations.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tero Kivinen
> Sent: Friday, December 19, 2008 12:50
> To: [email-masked]
> Subject: [IPsec] Redirect draft and REDIRECT_ACK notify
> 
> Scanned by Check Point Total Security Gateway.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 19 Dec 2008 13:51:09 -0800

Hi Tero,

> indicate for me that following exchange is valid:

It was never possible for the client to reject the REDIRECT message
from the gateway. The REDIRECT_ACK was just to confirm to the gateway
that the client did process the REDIRECT payload and understands that
it can no longer use the current gateway.

I think I was missing the fact that you can ack a message with just an
empty response. Thats why I was using the REDIRECT_ACK payload to
explicitly indicate that the REDIRECT payload was processed and
understood.

If an empty message is sufficient, then obviously specifying an
additional payload, REDIRECT_ACK in this case, does not make sense.
This is fine with me.

> payloads when it is ready to delete the IKE SA.

Yaron had brought this up offline. In my working version of the draft,
I have already clarified this. The current text reads

   Once the client responds to the gateway with the REDIRECT_ACK
   payload, 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.  However, it
   should allow sufficient time for the client to setup the required
   security associations with the new security gateway.  This time
   period should be configurable on the gateway.

>   from the client.

In this case, I want the gateway to be able to delete the IKE SA
without sending an INFORMATIONAL message to the client. The re-direct
could be happening due to an overload. At this point I don't want the
gateway to send additional messages to the client. It already did send
the REDIRECT message to the client. So it will just implicitly delete
it.

Vijay

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 21 Dec 2008 14:30:46 +0200

> recipient of an empty acknowledgement may not know whether the other side

I do not think we need it. The client has already announced the
support for the redirect protocol by sending N(REDIRECT_SUPPORTED) in
the IKE_SA_INIT. The server has not indicated support for it yet, but
on the other hand it is the one who is starting the redirect by
sending the N(REDIRECT) to the client, and it is only allowed to send
that if the client has announced that it supports redirect protocol in
the IKE_SA_INIT. 

> gateway-to-gateway situations.

That would only be needed there in case the original initiator wants
to redirect the other end to some other server, but as he was the
original initiator, it might be easier for him to just to tell the
other node where he wants the responder to connect to start connection
to the original responder, and close his own SA.

Opening cases where both ends can redirect other ends, will cause
other complications, so those do require more thinking. This was the
reason why mobike mostly left that kind of situations out of scope (or
mostly left out the rendezvous servers needed in that kind of
situations).

Bidirectional N(REDIRECT_SUPPORTED) is not needed unless you want
change the roles of the initiator/responder and want to original
responder to become initiator that connects to some other server.

If that kind of scenario is needed, we need to add more text to draft
and describe it, I do not think we want to allow it by just saying
N(REDIRECT_SUPPORTED) is sent in both directions, and both ends can
send N(REDIRECT) notifies.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 21 Dec 2008 14:44:48 +0200

> it can no longer use the current gateway.

Good.

> explicitly indicate that the REDIRECT payload was processed and

Yes, after I sent the email I realized that the protocol you described
would be what you would use for IKEv1, but as in IKEv2 we do have
always request - response pairs and empty response do acknowledge that
the other end received the request, that is what we should be using
here. 

>    period should be configurable on the gateway.

That text is ok for me, altought I would also add similar text about
delete payloads to the gateway deleting SAs case. Also including those
delete payload as INFORMATIONAL exchange to the message examples would
be good. 

> the REDIRECT message to the client. So it will just implicitly delete

That is not really acceptable as IKEv2 protocol extension. The IKEv2
is reliable protocol, all exchanges are request - reply pairs, and IKE
SA is normally only deleted by delete payload. IKE SA will also be
deleted because of error situations, i.e. in case the other end does
not send reply to the request you sent (after multiple retries etc).

If the gateway is really that badly out of resources then it will most
likely run out of resources when trying to send the delete
notification and that out of memory type of situation is fatal, and
will cause the server to delete the IKE SA. As client does not get any
message about that it can still try to use the IKE SA until the dead
peer detection will delete the IKE SA because server does not reply to
the liveness requests. This is not normal situation, and we do not
want to standardize that any implementation may be using such method.

If the server is really that badly out of resources, it can include
the N(REDIRECT) and D() payloads in the same INFORMATIONAL exchange,
and ask client to redirect to new server and delete the IKE SA at that
same request. If it allowed client for some time to clean up state and
reconnect to new server, then it should allow client time to delete
the IKE SA also. Client do not have any reason NOT to delete the IKE
SA, so why would the client not delete the old IKE SA.

Only reason I can see which could cause the client not to delete the
IKE SA quickly is that the server where N(REDIRECT) asked client to
connect, is not reachable, thus client will still keep old IKE and
IPsec SAs up until it gets new SAs up, but if the server is down, then
it cannot do that. If the server then suddenly silently delete the IKE
SA that will silently create the black hole for the client, causing
all the packets sent by client to be disappearing to black hole
without any indication to the user what happened. On the other hand if
server do send IKE SA after suitable timeout (say 30-60 seconds) then
client will get indication that the old SAs disappeared, and new are
not yet up, and it can indicate that properly to the user.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 21 Dec 2008 15:10:05 +0200

The scenario I have in mind is planned maintenance, where one cluster member
redirects all traffic to the other member. I think this situation is in
general not as complicated as in MOBIKE, but I may be missing something.

Thanks,
	Yaron

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Sunday, December 21, 2008 14:31
> To: Yaron Sheffer
> Cc: [email-masked]
> Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify
> 
> Yaron Sheffer writes:

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Dec 2008 14:36:39 +0200

> general not as complicated as in MOBIKE, but I may be missing something.

True, but doing it so that you just turn the traffic to go to the
another member first, and allow it create new IKE/IPsec SAs up first,
and when that is done, the old SAs are not used anymore so you can
bring them down (or the whole GW). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec