Subject: [IPsec] questions on redirection during IKE_AUTH

From: fan zhao <[email-masked]>
Date: Tue, 24 Feb 2009 10:19:57 -0800

Hi,

The current draft uses a separate informational message after the IKE_AUTH
to redirect the client.

However, while receiving the NO_ADDITIONAL_SAS in the last IKE_AUTH
(before the N(Redirect)
is received), the IPsec client may try to connect with another IPsec
gateway (it can select one from
a list of gateways, for example, returned by the DNS response).
Especially when during HO,
the client wants to perserve its IP address/mobility states, it needs
to do so since it knows
that the connection with the current IPsec gateway is unsuccessful.

Such the selected IPsec gateway may be different from the one that
will be indicated in the N(REDIRECT).
Therefore, when the client processes the N(Redirect), it may realize
that it needs to abort
the communication with another IPsec gateway, which results in overhead.

Furthermore, the current draft specifies that when the client receives
N(redirect), it MUST send an empty
message as an acknowledgement.

Considering the different order of N(Redirect), the delete request
from the client and the empty message
(as a response to n(Redirect)), there are different flows. For
example, N(redirect) could be lost, and the
delete request from the client could be sent before the client
receives the N(redirect), etc.

However, the current draft does not specify how to handle such cases.

>From the perspective of the client, there are three situations:
N(redirect) is lost,
N(redirect) is received before sending the Delete request, N(redirect)
is received
after sending the Delete request.

>From the perspective of the gateway, there are also three situations: the empty
message is lost, the empty message is received before receiving the
delete request
from the client, and the empty message is received after receiving the
delete request.

One special case is that N(redirect) is lost and the client sends a
delete request.
And in this case, the gateway cannot piggyback the N(redirect) together with
the delete payload. Because otherwise, the client cannot send back the empty
message to the gateway.

It seems to me to handle all these cases, the safest/simplest way is
that the gateway always
waits for the empty message to be received before it sends the
response to the delete
request from the client. However, one of reasons of doing redirection
is gateway overloading.
With this method, the gateway cannot release unuseful IKE SA as soon
as possible, which
prevents the gateway releasing resources and serving more clients.
Otherwise, the draft needs to specify in detail how to handle these cases.

Given the above reasons, I suggest that N(redirect) is carried in the
last IKE_AUTH message.
IMO, it seems to me it is ok to use the N(redirect) with the status
type during the IKE_AUTH as
RFC 4306 3.10.1 specifies that “Notify payloads with status types
MAY be added to any message and MUST be ignored if not recognized.”

What do you think? Thanks.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Feb 2009 15:04:03 +0200

> the communication with another IPsec gateway, which results in overhead.

Client should wait for the few milliseconds it takes to get the next
packet immediately following the IKE_AUTH reply before trying to
connect new gateways. If client wants to waste resources by doing
guesses where it will be redirected then that is its problem.

So I do not consider that protocol issue but issue with bad
implementations wanting to waste resources. We cannot really solve all
bad implementation issues, vendors can always make bad implementations
which waste even more resources.

For example the client can start connecting to all gateways in the
beginning even before receiving any REDIRECT notification. We do not
have anything in the draft forbidding (or allowing) that either, and
I do not think we need to cover all possible ways people can make bad
implementations. 

> message as an acknowledgement.

That requirement does not come from the redirect document, it comes
from the base IKEv2 specification, which mandates that each request
MUST receive reply.

The redirect document cannot really change the IKEv2 base document
requirements, thus all implementations implementing IKEv2 will already
require that same thing. 

> However, the current draft does not specify how to handle such

The draft does not need to specify such things, as those are not
redirect specific cases, they are generic IKEv2 questions.

Base IKEv2 RFC already covers what do when packets are lost, and how
redirects are handled in that case.

The current IKEv2 RFC does not specifically tell how to handle the
ongoing exchanges when delete notification is sent.

It does say that delete payload deleting IKE SA must be last REQUEST
sent over an IKE SA (section 2.8). As the generic requirement for
IKEv2 exchange handling is that it MUST be able to process incoming
requests at any time (even when it has already send out delete request
himself, but not received reply for it yet), the node which have sent
delete request out, must still process all incoming notifications
(including N(REDIRECT)) until it receives reply to the delete
notification.

On the other hand the other end who has already started some other
exchange with the other node (for example who has sent N(REDIRECT)
request) might want to postpone replying to the delete notification
until it gets the reply for all ongoing requests it has sent out. In
most cases that does not matter, as deleting IKE SA will also delete
all data associated with it, thus it does not matter whether it waits
replies or not, as those replies can only affect things that will be
deleted when IKE SA is deleted, but REDIRECT notification also affects
future IKE SAs, thus it should not reply to the delete payload
deleting IKE SA until it has received reply for its N(REDIRECT)
request.

It can also include N(REDIRECT) in to the reply to be sent to delete
payload, as was explained already in the mailing list. The responder
will then get either of those N(REDIRECT) payloads (either the
original request, where it will then send reply, or the reply to the
delete payload deleting IKE SA, in which case there will not be any
other packets sent out (replies are only sent to request, replies are
never sent out for received replies).

This behavior is completely valid based on the RFC4306. The reply
received for the delete payload deleting IKE SA is just normal reply
message, thus it will still be processed as normally. For example the
section 5.8 for RFC 4718 says that normally there is no information
that needs to be sent to the other side, thus empty information
response is usually used, but in this case we do have information we
want to send, thus we can just put the N(REDIRECT) there to give that
information.

Note, that N(REDIRECT) notification payload DOES NOT require any
reply, thats why the normal reply message to the request containing
N(REDIRECT) will be empty message.

> delete request. And in this case, the gateway cannot piggyback the
> N(redirect) together with the delete payload. Because otherwise, the
> client cannot send back the empty message to the gateway.

The request client send contains the delete payload, the reply to that
packet normally is empty payload (i.e. there is no delete payload in
reply). In this case it would be completely legal to include the
N(REDIRECT) notification in the reply packet.

The empty message reply is only required if N(REDIRECT) is sent as
separate INFORMATIONAL exchange, i.e. it is sent out as request, not
as reply. Every single request in IKEv2 do require reply packet to be
sent back. Thus the requirement for empty message does not come
because we sent N(REDIRECT), it is there because every single request
must receive reply.

If N(REDIRECT) is included in the reply packet then there will not be
any more packets to that exchange. The sender of N(REDIRECT) will know
that other end received it as it stopped retransmitting its request
(in IKEv2, the initiator of the exchange is always responsible to
retransmit the packet until it receives reply or decided the other end
has died). 

> that the gateway always waits for the empty message to be received
> before it sends the response to the delete request from the client.

That is also valid implementation. This is again implementation
detail, that does not really affect the protocol, only the
implementations.

> However, one of reasons of doing redirection is gateway overloading.
> as possible, which prevents the gateway releasing resources and
> serving more clients. Otherwise, the draft needs to specify in
> detail how to handle these cases.

In that case it is better to redirect already during IKE_SA_INIT, and
not waste gateway resources by finishing IKE_AUTH at all. That is the
most resource consuming part of the IKE SA, thus if gateway is
overloaded, then redirect before using that much resources. 
-- 
[email-masked]

---

From: fan zhao <[email-masked]>
Date: Wed, 25 Feb 2009 14:54:25 -0800

Hi Tero,

Please see below.

> guesses where it will be redirected then that is its problem.

RFC 4306 and IKEv2bis do not specify that "Client should wait for the
few milliseconds it takes to get the next packet immediately following
the IKE_AUTH reply before trying to connect new gateways."
This sounds like a new requirement to me.
Furthermore, considering that the IPSec gateway sends the NO_ADDITIONAL_SAS
not because of redirection, but because of be unwilling to accept the child
SA, there is no point that the client needs to wait because the gateway
will not send the N(Redirect) in this case. Also, when the N(redirect)
is sent in the case of redirection, the informational message carrying
the N(redirect) may be lost. So even if the client waits, it may still start
IPsec SA establishment with the new gateway.

> which waste even more resources.
This issue is because the NO_ADDITIONAL_SAS is re-used during the IKE_AUTH
in case of redirection, which results in overheads. The NO_ADDITIONAL_SAS
originally is not defined for the redirection purpose.

> I do not think we need to cover all possible ways people can make bad
That is a bad implementation indeed. In fact, not only resources
are wasted, but also it requires that the implementation
of the client be able to identify and delete the useless SAs to obtain
the same service later.
I do not think any sensible implementor will do that. However, it makes sense
when the NO_ADDITIONAL_SAS is received, the client tries to connect to
a new gateway.

> from the base IKEv2 specification, which mandates that each request
Yes.

> requirements, thus all implementations implementing IKEv2 will already
OK.

> redirects are handled in that case.
The issue here is that when the client receives the N(NO_ADDITIONAL_SAS)
and before receiving the N(Redirect), it decides to delete the IKE SA since
such a SA is useless. When the gateway receives such delete request, it
does not know whether the N(Redirect) has already been received. Therefore,
it cannot delete the IKE SA because if the N(redirect) is lost and the IKE SA
is deleted, the gateway cannot re-transmit the N(redirect). This is the case
specific to the redirection. It is possible for the gateway to include
the N(redirect)
in the reply to the delete request, please see below for more on this.

> ongoing exchanges when delete notification is sent.
Maybe because the scenario of redirection is not considered?

> (including N(REDIRECT)) until it receives reply to the delete
Yes, agreed.

> deleting IKE SA until it has received reply for its N(REDIRECT)
Yes.

> never sent out for received replies).
Yes. Nevertheless, when the client receives the N(Redirect) in an informational
request, it may start the IKEv2 with the new IPsec gateway. Now, if it
receives another N(Redirect) in the reply to the delete request, the
implementation
needs to check whether the IKEv2 SA establishment with the new IPsec
gateway has already started as a response to the N(Redirect).
It increases implementation complexity because the implementation needs to
distinguish this case from other cases where the client
may actually want to establish multiple IKE sessions with the same IPsec
gateway.

Furthremore, the N(redirect) is important information that affects the future
SA setup, as you said. However, if the reply to the delete request and
the N(Redirect)
included therein are lost, and if the IPsec gateway deletes the IKE SA
immediately
when processing the delete request from the client, the client cannot receive
the redirection information. If the IPsec gateway does not delete the IKE SA
immediately when processing the delete request from the client, there is
impact on performance, as identified below.

Given N(Redirect) is important for the client, we should include it in
the IKE_AUTH
(which is a more critical signaling message) to ensure it can be
delivered to the
client reliably.

> want to send, thus we can just put the N(REDIRECT) there to give that
OK. Please see above.

> N(REDIRECT) will be empty message.
OK.

> reply).
Umm, if the client requests to delete the SA by sending the delete payload
in the informational request, isn't that the gateway needs to send back a
reply with the delete payload? I do not understand this sentence.

> In this case it would be completely legal to include the
OK. Please see above.

> because we sent N(REDIRECT), it is there because every single request
OK.

> any more packets to that exchange.
Yes. However, the reply (N(redirect) is included therein)
to the delete request may be lost, right? It may be
less likely, but a robust system needs to consider this possible scenario.

> The sender of N(REDIRECT) will know
It is also possible that when during the IKE_AUTH, the IPSec gateway
realizes it is overloaded, for example, many data packets belonging to
the already established IPSec SA need to be processed. Therefore,
the IPsec gateway issues N(redirection) to the client.

Thanks for your reply.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Feb 2009 16:20:16 +0200

> the IKE_AUTH reply before trying to connect new gateways."

RFC4306 does not specify that client MUST immediately close the IKE SA
down if it receives NO_ADDITIONAL_SAS during IKE_AUTH. RFC4306 does
not say anything about the matter.

> This sounds like a new requirement to me.

REDIRECT is new requirement, it does cause changes to the
implementations, and this is one of those changes, that if
implementation was written so it immediately deleted the IKE SA if
IKE_AUTH received NO_ADDITIONAL_SAS, then it would be better to change
it so it will instead wait for few seconds before deleting the IKE SA.

You cannot implement REDIRECT without making any changes to the
implementation.

Note, that REDIRECT will still work even if you do not wait. It is
just bad implementation to immediately delete the IKE SA at that
point, as it will most likely just cause busy loop consuming
resources.

I.e. if the other end happened to return NO_ADDITIONAL_SAS not because
of REDIRECT, but because it could not create new IPsec SAs even when
it could create IKE SAs. If client implementation immediately deletes
IKE SA and starts over, it will create busy loop doing Diffie-Hellmans
and authentication and creating new IKE SA as fast as it can, and then
delete it again if server still does not have any resources. Much
better implementation will add some timer there and will not try again
as fast as possible, but instead wait for few tens of seconds to allow
server to perhaps free up resources, or at least slow down the busy
loop. This does not have anything to do with redirect, it is just how
good implementation should behave in general.

> will not send the N(Redirect) in this case. Also, when the N(redirect)

As I explained above it is better to wait even in that case, as
otherwise you just busy loop and create accidental denial of service
attack against the server.

> originally is not defined for the redirection purpose.

NO_ADDITIONAL_SAS was defined to be used in cases where "responder is
unwilling to accept any more CHILD_SAs on this IKE_SA.". This is
exactly the case here in the REDIRECT case too. I.e. server does not
want to allow new CHILD_SAs on this IKE_SA as it knows it will
redirect the client away.

It is true that the description only mentioned CREATE_CHILD_SA
request, but in most cases the initial IPsec SA creation happening
during the IKE_AUTH is handled identically to the CREATE_CHILD_SA.
Exceptions where they receive special handling is listed specifically
(i.e. KEYMAT generation etc).

> The issue here is that when the client receives the
> N(NO_ADDITIONAL_SAS) and before receiving the N(Redirect), it
> decides to delete the IKE SA since such a SA is useless. When the
> gateway receives such delete request, it does not know whether the
> N(Redirect) has already been received.

It will know that it has not received reply to the N(REDIRECT). 

> Therefore, it cannot delete the IKE SA because if the N(redirect) is
> lost and the IKE SA is deleted, the gateway cannot re-transmit the
> N(redirect). This is the case specific to the redirection. It is
> possible for the gateway to include the N(redirect) in the reply to
> the delete request, please see below for more on this.
> 
> >

Not really. The reason it does not cover what happens to the exchange
during IKE SA rekey or when IKE SA is deleted, is that those details
were just omitted.

The delete case is not usually the problem, as when IKE SA is deleted,
there is nothing left, meaning there is no need to think what happens
to the ongoing exchanges. N(REDIRECT) changes this bit, as this notify
will not affect the IKE_SA, it will affect the client state outside
the IKE SA, thus it makes big conceptual change to the IKE SA. Thats
why the redirect draft needs to specify what happens if you have
ongoing N(REDIRECT) out and you receive delete notification for the
IKE SA.

The bigger generic problem is what happens to the ongoing exchanges
during IKE SA rekey.  This gets very complicated if you have window
size bigger than one, but that is outside the scope of this
discussion. 

> Furthremore, the N(redirect) is important information that affects
> the future SA setup, as you said. However, if the reply to the
> delete request and the N(Redirect) included therein are lost, and if
> the IPsec gateway deletes the IKE SA immediately when processing the
> delete request from the client, the client cannot receive the
> redirection information. If the IPsec gateway does not delete the
> IKE SA immediately when processing the delete request from the
> client, there is impact on performance, as identified below.

The IPsec gateway must keep the IKE SA up to allow the other end to
redirect its delete request just in case the reply was lost, so the
gateway will be there to retrasmit its reply to delete request, even
if it has already processed the delete request.

As IKEv2 is reliable protocol the N(REDIRECT) and the delete payloads
will be acknowledged, thus the client will receive them.  

> reply with the delete payload? I do not understand this sentence.

No. You only include delete payload in both directions when you delete
CHILD_SAs. IKE SAs are deleted by sending delete payload in the
request, and receiving reply to that. Usually that reply is empty, but
in this case it could also include N(REDIRECT). 

> less likely, but a robust system needs to consider this possible scenario.

If it is lost, then client will resend its request which contains
delete payload, and other end will keep IKE SA up for suitable timout,
so it can resend its own reply to that delete request. This is part of
standard IKEv2.
-- 
[email-masked]