Subject: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft)

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 1 Dec 2008 11:06:05 -0800

Hi Fan,

I am following up on the one open issue on allowing a re-direct during
IKE_AUTH stage.

Yaron mentioned during the meeting in Minneapolis that this is not
really necessary. It just adds complexity to the state machine on both
the client and the gateway. I agree with him. I think the current
mechanisms, re-direct during the IKE_SA_INIT exchange and
gateway-initiated re-direct, are sufficient.

Vijay

On Wed, Nov 5, 2008 at 2:33 PM, fan zhao <[email-masked]> wrote:
> Hi Vijay,
>
> Thanks for your reply. Please see below.
>
> On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli <[email-masked]> wrote:
>> Hi Fan,
>>
>> On Tue, Nov 4, 2008 at 3:09 PM, fan zhao <[email-masked]> wrote:
>>> Hi, Vijay and Killian,
>>>
>>> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01.
>>>
>>> 1) The draft describes the redirection during the IKE_SA_INIT exchange
>>> and during the informational exchange that is after the SA is established.
>>> Please correct me if I am wrong. I think the redirection can be done during
>>> the IKE_AUTH exchange, right? We have discussed this before.
>>
>> Yes, but this change has not been made yet. I had presented this issue
>> at the last IETF, but there were no comments. I was looking for a
>> little bit more discussion on this before adding this to the document.
> OK.
>
>>
>>> 2) Near the end of section 3:
>>>
>>>   "When this mechanism is used with Mobile IPv6, a mobile node's
>>>   security associations with its home agent may expire while it still
>>>   has a valid binding cache entry at the home agent."
>>> Based on RFC 4877, the lifetime of a dynamically assigned HoA is
>>> the same as that of the SA. So if the SA expires, the HoA expires
>>> and the BCE is invalid too, right?
>>
>> The home address and the binding cache entry are not marked invalid
>> right away. If the SAs expire, the mobile node can run IKEv2 with the
>> home agent again and request for the same home address.
> OK. This can be done.
>
>>
>>>   "In this case, the
>>>   mobile node MUST NOT use the original home agent address as the
>>>   destination address in the IKE_SA_INIT exchange to setup new security
>>>   associations.  It MUST try to setup security associations with its
>>>   existing home agent."
>>>
>>> If I understand correctly, in this case, the MN will use the anycast address
>>> in the IKE_SA_INIT, and then is redirected to the original home agent.
>>> Is this correct?
>>
>> No, we wanted to say that the mobile node should try running IKEv2
>> again with the existing home agent. Not use the anycast address as the
>> destination address for the IKE_SA_INIT exchange.
>
> I agree with what you said. Somehow, I read the text differently.
>
> Thanks.
>
> Sincerely,
> fan
>
>>
>>> 3) Some editorial issues:
>>>
>>> Abstract: The proposed mechanism can
>>>   also be used for Mobile IPv6 to enable the home agent to re-direct
>>>   the mobile node to another home agent.
>>>
>>> Maybe it is better:
>>> "The proposed mechanism can also be used in Mobile IPv6 ..."
>>>
>>>
>>> 3.  IKEv2 Exchange with Redirect
>>>   To redirect a IKEv2 session to
>>>
>>> s/a/an
>>
>> Thanks for catching these.
>>
>> Vijay
>>
>>>
>>> Thanks.
>>>
>>> Sincerely,
>>> fan
>>>
>>>
>>> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli <[email-masked]> wrote:
>>>> Hi,
>>>>
>>>> We just submitted a new draft version for the IKEv2 re-direct
>>>> mechanism. Changes made in this version
>>>>
>>>> - Added a section on gateway-initiated re-direct. The earlier versions
>>>> only spoke about re-direct during the IKE_SA_INIT exchange
>>>> - Updated the reference to IKEv2bis draft
>>>> - A few other minor fixes.
>>>>
>>>> Vijay
>>>>
>>>>
>>>> 2008/11/3  <[email-masked]>:
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.
>>>>>
>>>>>
>>>>>        Title           : Re-direct Mechanism for IKEv2
>>>>>        Author(s)       : V. Devarapalli, K. Weniger
>>>>>        Filename        : draft-ietf-ipsecme-ikev2-redirect-01.txt
>>>>>        Pages           : 12
>>>>>        Date            : 2008-11-03
>>>>>
>>>>> IKEv2 is a popular protocol for setting up VPN tunnels from a remote
>>>>> location to a gateway so that the VPN client can access services in
>>>>> the network behind the gateway.  Currently there is no standard
>>>>> mechanism specified that allows an overloaded VPN gateway to re-
>>>>> direct the VPN client to attach to another gateway.  This document
>>>>> proposes a re-direct mechanism for IKEv2.  The proposed mechanism can
>>>>> also be used for Mobile IPv6 to enable the home agent to re-direct
>>>>> the mobile node to another home agent.
>>>>>
>>>>> A URL for this Internet-Draft is:
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-01.txt
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> Below is the data which will enable a MIME compliant mail reader
>>>>> implementation to automatically retrieve the ASCII version of the
>>>>> Internet-Draft.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IPsec mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>
>>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>
>>
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Tue, 2 Dec 2008 11:11:08 -0800

Hi Vijay,

Thanks for following up on this issue. Please see my reply below.

On Mon, Dec 1, 2008 at 11:06 AM, Vijay Devarapalli <[email-masked]> wrote:
> really necessary.
I think the advantage of doing this during the IKE_AUTH is to avoid
overheasd because if the IPsec client is redirected during the informational
exchange, more signaling messages are sent and the states regarding
the SA are created unnecessarily. Even worse, the client may request
to set up the child SA during the IKE_AUTH. Note that redirection during
the informational exchange is still useful in other cases; however, if the
IPsec gateway knows it needs to redirect the IPsec client to another
gateway, it does not have to wait until the IKE_AUTH is completed.

> It just adds complexity to the state machine on both
> the client and the gateway.
The following cases are possible if the redirection is done during IKE_AUTH:
1) The IPsec client does not request to set up the child SA during IKE_AUTH
client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH}
The IPsec gateway verifies such message (may use EAP also), if
the authentication fails, the IPsec gateway indicates the error without
providing the REDIRECT payload to the client per rfc 4306.
If the authentication succeeds, the IPsec gateway returns the following
message with the REDIRECT payload.
gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]}
The client authenticates this message. If fail, the client ignores this
message and may try with the same or different IPsec gateway again.
If authentication succeeds, the client performs redirection based on the
REDIRECT payload.

2) The IPsec client requests to set up the child SA during IKE_AUTH
client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr}
The IPsec gateway verifies such message (may use EAP also), if
the authentication fails, the IPsec gateway indicates the error without
providing the REDIRECT payload to the client per rfc 4306.
If the authentication succeeds, the IPsec gateway returns the following
message with the REDIRECT payload.
gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]}
The client authenticates this message. If fail, the client ignores this
message and may try with the same or different IPsec gateway again.
If authentication succeeds, the client performs redirection based on the
REDIRECT payload.

I do not see too much complexitiy. It is worth documenting redirection
during the IKE_AUTH given the benefits. In fact, it only needs a few sentences.
What do you think?

Sincerely,
fan

> I agree with him. I think the current

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 3 Dec 2008 00:32:59 +0200

Hi Fan,

To clarify: in the case of EAP, you are looking for redirect *only* in the
last message of the IKE_AUTH exchange, right? And the motivation is to
redirect (to choose the destination gateway) based on the client's
authenticated identity?

I think that with EAP, if you want to redirect because of overload
conditions, then having the AAA server work hard and only then redirecting
the client (and repeating this effort somewhere else) doesn't make much
engineering sense.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
fan zhao
Sent: Tuesday, December 02, 2008 21:11
To: Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2
Re-direct draft)

Hi Vijay,

client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi,
TSr}

I do not see too much complexitiy. It is worth documenting redirection
during the IKE_AUTH given the benefits. In fact, it only needs a few
sentences.
What do you think?

Sincerely,
fan

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Tue, 2 Dec 2008 15:30:22 -0800

Hi Yaron,

On Tue, Dec 2, 2008 at 2:32 PM, Yaron Sheffer <[email-masked]> wrote:
> last message of the IKE_AUTH exchange, right?
Yes.

> And the motivation is to
Yes.

> the client (and repeating this effort somewhere else) doesn't make much
In this case, redirection is not because of load condition. It is because
the network (such as AAA server or other backend server) has user profile
and the profile stores the IPsec gateway that the client needs to connect to;
however the client selects a different gateway initially.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Dec 2008 14:51:34 +0200

> client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr}

If we want to allow redirection during the IKE_AUTH, I think this
second option is the one we want to select. This would be identical to
normal exchange, thus it will cause smaller changes, and it has good
property that if server does NOT do redirect we get the IPsec SA done
after this. In any cause we MUST NOT define two different ways how to
do this, as that would just add unnessary complexity. So if we are
going to select one, lets select this one.

On the other hand the difference between doing the IKE_AUTH to end and
doing INFORMATINAL exchange after that to do redirect is even
simplier, as we still want to support that option too, and the most
time consuming part of the IKE_AUTH (Diffie-Hellman, Signing etc) is
already done anyways, so doing it as separate INFOMRATIONL exchange,
simply wastes 2 extra small packets but no extra round trips. Note,
that server can reject the IPsec SA creation by returning suitable
error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and
then the full exchange would be:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni,
        N(REDIRECT_SUPPORTED)  -->

                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

   HDR, SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH, SAi2,
        TSi, TSr}  -->

                                <--  HDR, SK {IDr, [CERT,] AUTH,
                                          N(NO_ADDITIONAL_SAS)}
                                <--  HDR, SK {N(REDIRECT)}

   HDR, SK {N(REDIRECT_ACK)} -->
   HDR, SAi1, KEi, Ni,
        N(REDIRECT_FROM)  -->

I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after
that send N(REDIRECT) notify as separate INFORMATINAL exchange. The
initiator would first get the IKE_AUTH reply, process that, and
immediately after that get INFORMATINAL exhange asking to N(REDIRECT).

The initiator can start connection to the new IKE SA immediately when
it receives the N(REDIRECT) thus it does not waste any single round
trip, only wasted resource would be 2 small packets (less than 100
bytes each). 

I think this is simplier and cleaner way to get the same effect with
no extra real cost.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Wed, 3 Dec 2008 11:05:38 -0800

Hi Tero,

Thanks for your reply.
If you do not mind, I will call redirection in the last message
during the IKE_AUTH as "redirect_auth" and redirection during
the separate informational exchange as "redirect_info" in the following text.

On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen <[email-masked]> wrote:
> after this.
I think this property is also supported by the redirect_auth since if
the IPsec server does not want to do redirect, it simply does not include
the Redirect payload.

> In any cause we MUST NOT define two different ways how to
This is always a good principle to follow in general. However, in this case, my
understanding is that the redirect_auth and the redirect_info address
different needs. For example, when an IPsec server serving IPsec clients
realizes that it is overloaded or it needs to shut down for
administration reasons,
the server can inform the clients by using redirect_info.
On the other hand, when the IPsec server realizes that the client connects
to a different server from the one in the client's profile, it
performs the redirect_auth
that IMO is simpler and mroe efficient that the redirect_info in this case.
I do not see they are two different methods for the same purpose.

> then the full exchange would be:
What happens if these two messages from the server are reordered
during transmisstion, and either HDR, SK {N(REDIRECT)} or
HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped
during transmission?

Thanks.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Dec 2008 15:23:44 +0200

> the IPsec server does not want to do redirect, it simply does not include

That would not be possible for the first option you gave, i.e. the one
I did not include in my email. The one having only HDR, SK {IDi,
[CERT,] [CERTREQ,] [IDr,] AUTH}, as there is not enough information
there to creat ethe IPsec SAs (i.e. the SAi2, TSi, and TSr are
missing).

> I do not see they are two different methods for the same purpose.

Yes, they are for different purposes, but on the other hand we can
still use one way to solve both purposes, with only 2 extra 100 byte
packets as an overhead (no round trips or anything like that).

> HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped

Nothing special. The Client will either drop the N(REDIRECT) request
if it comes before the reply for IKE_AUTH, or it will keep it on hold
until the IKE_AUTH is processed. In any case it MUST to do the same
thing it does normally when it receives request from the other end
before it has received reply to the IKE_AUTH, i.e. it must process the
IKE_AUTH first and check the AUTH payload before it is allowed to
process any other requests from the other end.

Note, that this is not special case for the N(REDIRECT), this thing
can also happen with CREATE_CHILD_SA or any other exchange too. Our
implementation will simply drop all those new request until it gets
the reply back to the IKE_AUTH (just checked it with create child sa
exchanges to be sure our code works correctly :-).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Thu, 4 Dec 2008 12:57:23 -0800

Hi Tero,

> there to creat ethe IPsec SAs (i.e. the SAi2, TSi, and TSr are
Sorry I did not make myself clear. The first option I listed is the case
where the client does not want to set up a child SA during the IKE_AUTH.
If the client wants to do that, it can send the message as described
in the second option I listed. I listed two options separately, but
with the redirect during the IKE_AUTH, the SA can be established if the
client wants to create the child SA and the server does not need to redirect
the client.
> packets as an overhead (no round trips or anything like that).
Actually I think the redirect during the IKE_AUTH is similar to
the redirect during the IKE_SA_INIT with the unicast IPsec gateway,
with the only difference that is during the IKE_AUTH, the IPSec
gateway takes not only its load condition but also the ID of the client
into consideration.
I agree that the redirect during the informational exchange works in
both cases. However, if it is more efficient and does not introduce
much complexity, I do not see why we do not take advantage of
the already defined REDIRECT payload and use it during the IKE_AUTH.
Using one way for multiple purposes in general is good to simplify
the solution. In this case, I do not see much benefit by excluding
the REDIRECT payload from the IKE_AUTH.

> process any other requests from the other end.
I never doubt that there are methods to handle packet reordering and loss.
Nevertheless, if the REDIRECT payload is carried in the message,
we do not have to worry about these conditions and consequences.

> exchanges to be sure our code works correctly :-).
Good for you ;-)

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Dec 2008 13:38:06 +0200

> where the client does not want to set up a child SA during the IKE_AUTH.

There is no such option currently. The SAi1, TSi, and TSr payloads are
NOT OPTIONAL in the IKE_AUTH. I see no point to adding such option, as
if the client does not want to create IPsec SA with the server, why
did he connect in the first place.

> client wants to create the child SA and the server does not need to redirect

RFC4306 and ikev2bis documents do not offer such option, so I
naturally assumed you wanted to add that option for special case for
redirect case just in case client does not want to create IPsec SA
because he assumes server will redirect him somewhere else. Even in
that case the client usually would not have information whether server
will redirect him or not, so he should always try to create IPsec SA
and if server wants to redirect client, then it can refuse creation of
the IPsec SA as it would be teared down immediately when client
disconnects and reconnects to another place. 

> gateway takes not only its load condition but also the ID of the client

The reason for doing redirect during IKE_SA_INIT is to avoid server
doing any expensive calculations, thus not making loaded server even
more loaded by doing Diffie-Hellman and signature calculations before
redirecting clients to not so loaded servers. In the IKE_AUTH the
server has already done all those calculations so there is no benefit
for doing it inside the IKE_AUTH compared to separate INFORMATIONAL
exchange. 

> the already defined REDIRECT payload and use it during the IKE_AUTH.

It adds yet another mode that needs to be tests. That mode needs to be
tested with all possible authentication combinations (4 + EAP methods
* 2). It needs to be tested with other initial exchange combinations,
i.e. INVALID_KE_PAYLOAD and COOKIE notification cases, it needs to be
tested with MOBIKE extensions, it needs to be tested with NAT
traversal cases, etc.

Adding one more mode there adds lots of complexity to testing effort
and also makes the already complicated IKE_AUTH state machine even
more complicated.

So I strongly disagree your comment that it "does not introduce much
complexity". I also mostly disagree your comment that it "is more
efficient", as I do not see 2 * 100 byte packets, without any
additinal round trips or similar really that much more efficient that
it would matter.

> the REDIRECT payload from the IKE_AUTH.

Then we disagree on that, as I do see major benefit of not making the
most complex part of the IKEv2 even more complex.

> we do not have to worry about these conditions and consequences.

Complient IKEv2 implementation MUST be able to handle packet
reordering and loss regardless whether we make this extension or not.
REDIRECT notify does not add any new requirements for this part, it is
already there, and if implementation does not handle packet reordering
or packet loss, it is complectely broken and unsecure.

I.e. if for example the client would accept CREATE_CHILD_SA before
checking the IKE_AUTH auth payload, that would allow attacker to do
following active attack:

   Initiator                         Attacker
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni -->
		   Attacker makes sure the packets do not ever reach
		   the intended destination, but instead intercepts
		   them and responds to them himself. 

		   As the attacker send the KEr instead of the real
		   responder, he is able to do Diffie-Hellam
		   calculations and getting the keying material for
		   the packet. Now the client would notice the man in
		   the middle if attacker would send reply to this
		   IKE_AUTH as attacker would not be able to generate
		   valid AUTH payload. So he does not send IKE_AUTH at
		   all, but instead starts new CREATE_CHILD_SA
		   exchange with client. 

                                <--  HDR, SK {SA, Ni, TSi, TSr }

   If the client will process the create
   child sa before verifing the AUTH
   payload of the IKE_AUTH (which
   has not been sent) it attacker
   can create IPsec SA with Initiator
   where the Initiator belives
   the other end is valid Responder

So the Initiator in this case MUST not reply to the new
CREATE_CHILD_SA as otherwise he opens himself to big security hole.

This is specified in the section 1 of the RFC 4306 (and IKEv2bis):
----------------------------------------------------------------------
						   ... In all cases,
   all IKE_SA_INIT exchanges MUST complete before any other exchange
   type, then all IKE_AUTH exchanges MUST complete, and following that
   any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
   in any order.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Fri, 5 Dec 2008 09:58:40 -0800

Hi Tero,

> did he connect in the first place.
I thought that the client does not have to create the child_sa during
the IKE_AUTH,
it can do that after the IKE_AUTH. That is what I meant. I do not intend to add
any new option for child sa establishment.

> because he assumes server will redirect him somewhere else.
Sorry for causing confusion. That is not my intention. Please
see my clarification above.

> Even in
> redirecting clients to not so loaded servers.
Yes, I understand.

> In the IKE_AUTH the
That is where we differ. See more on this below.

> tested with all possible authentication combinations (4 + EAP methods
I do not see why adding the REDIRECT payload can affect the authentication
combination. The authentication of the last IKE_AUTH message is done
independently and actually before the processing of the REDIRECT payload.
Sure, we should consider all possible cases. Do you find anything broken?

> tested with MOBIKE extensions, it needs to be tested with NAT
Still I do not see anyhting could be broken. To my best knowledgement,
I do not see this can break MOBIKE and NAT traversal either.
Can you give me an example?

> and also makes the already complicated IKE_AUTH state machine even
By the testing effort, do you mean the "conditions" in the program or
the testing cases? There are many different ways for implementation.
>From the protocol perspective, the state transition is simple:
after all the processing, specified in the IKEv2 protocol, of the last IKE_AUTH
message, then the client processes the REDIRECT payload.

> additinal round trips or similar really that much more efficient that
I worry more about the "consequence" of packet reordering/loss.
See more on this below.

> or packet loss, it is complectely broken and unsecure.

I agree that packet reordering/loss can be handled. But even so, delay and
overhead are introduced. As an example, assume that the server sends
the last IKE_AUTH message and then a informational message with
the REDIRECT payload. If the informational message is lost during the
transmission, the server does not know until it receives an IPsec packet
from the client again; then the server needs to send another informational
message with the REDIRECT payload to the client. In this case, the client
would waste a packet and IPsec processing time on this packet, and the
client cannot connect to the correct server as soon as possible. This is
not good especially when there is existing session between the client and
the correct server.
So my point is if there is a way to avoid dealing with such situations
then it is good to use it.

> checking the IKE_AUTH auth payload, that would allow attacker to do
Thanks for explanation. Yes I agree with you: so in the redirection
case, if the
REDIRECT payload is received before the last AUTH message (i.e. reordering),
the client shoudl reject it.Then the server would have to send another REDIRECT
payload to the client again after it realizes that the client is not
redirected yet, right?
Thanks.

Sincerely,
fan

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Dec 2008 09:44:46 +0200

> did he connect in the first place.

This question comes up every few months. Connecting (setting up an IKE  
SA) involves user interaction, and for clients it is user-initiated  
rather than traffic-initiated.

When the user clicks the "connect" button, the client has no way of  
knowing what traffic it is going to protect. If the policy at the RA  
gateway is to have an IPsec SA for each pair of hosts, there is no way  
to determine which SA to setup initially. Later, when the IMAP client  
contacts the IMAP server, or the browser contacts the internal web  
site, it makes sense to set up SAs for these addresses.

With IKEv1 clients, we had the "connect" button do phase 1 (Main Mode  
and optionally XAuth) and then the Quick Mode was traffic-initiated.

With IKEv2, although you don't have any traffic, you have to set up  
some kind of IPsec SA, which may never be used. One was that is  
suggested by RFC 4306 is for the client to offer a global selector for  
the entire Internet, and then the gateway narrows it down to the  
encryption domain. But if for implementation reasons it needs to be  
further narrowed down (for example, either the client or the gateway  
can only work with single ranges per SA and would send the  
SINGLE_PAIR_REQUIRED notification), the first SA may be a dummy.

I know the current RFC does not allow creating only an IKE SA, and  
that we're not going to add such an option to the -bis, but I believe  
that it would make the whole client thing more sensible.

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Dec 2008 08:34:32 -0800

At 9:44 AM +0200 12/7/08, Yoav Nir wrote:
>With IKEv2, although you don't have any traffic, you have to set up some kind of IPsec SA, which may never be used. One was that is suggested by RFC 4306 is for the client to offer a global selector for the entire Internet, and then the gateway narrows it down to the encryption domain. But if for implementation reasons it needs to be further narrowed down (for example, either the client or the gateway can only work with single ranges per SA and would send the SINGLE_PAIR_REQUIRED notification), the first SA may be a dummy.

This was discussed a few times, and the general agreement was that the slight cost of a dummy SA was worth the benefit of of clarity of the spec. Personally, I think that having the remote access client always have a tunnel to an internal DNS server, even if there was no other tunnel, is a useful thing.

>I know the current RFC does not allow creating only an IKE SA, and that we're not going to add such an option to the -bis, but I believe that it would make the whole client thing more sensible.

We're not opening that up in IKEv2bis, so let's drop that thread.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 19:08:50 +0200

> Sure, we should consider all possible cases. Do you find anything broken?

The number of packets sent in the IKE_AUTH will change for EAP for
example, and the REDIRECT payload changes location depending what
authentication method is used (i.e. it would be in the last). This
means that at least EAP vs non EAP case is mandatory to test, but in
general good QA will test all possible combinations to make sure there
is nothing that breaks when other authentication methods are used.

I agree that making bug that is only affected by certain
authentication combination might not be the most common bug to make,
but on the other hand bugs do not tend to be very predictable in
general.

> Can you give me an example?

For example for NAT traversal you still need to make sure the client
uses correct port to connect the new server. The current draft does
not say whether client should connect to directly to port 4500 or
restart at port 500. Both of them do have benefits. With mobike the
complication could be for example that IP-addresses change between
IKE_SA_INIT and IKE_AUTH, or when combininig MOBIKE with NAT
traversal, you do the port float to port 4500 before you start
IKE_AUTH etc.

I cannot really guess what kind of bugs people tend to write... But
implementations usually do have bugs, and implementations needs to be
tested before they can be put out. The more options we have the more
testing there is to do.

> By the testing effort, do you mean the "conditions" in the program
> or the testing cases? There are many different ways for
> implementation. From the protocol perspective, the state transition
> is simple: after all the processing, specified in the IKEv2
> protocol, of the last IKE_AUTH message, then the client processes
> the REDIRECT payload.

I mean the test done by the QA before any release is done, and also
interoperability testing done in the IPsec interoperability events. 

> I worry more about the "consequence" of packet reordering/loss.

That is something your current QA people should already be testing
before you release anything, as it is critical security feature, and
if that is broken, then your implementation is unsecure.

This is something that MUST be done for the plain IKEv2 already, this
extension does not add any new requirements for this part.

> from the client again;

Server will know the informational packet was lost, as it does not
receive reply back from the client. This again is standard IKEv2
feature, that must be tested by the QA before any products can be put
out, as it affects the whole IKEv2 protocol implementation. 

> then the server needs to send another informational
> message with the REDIRECT payload to the client.

The server would not send another informational message, he would
resend the previous request, and he will resend it until the client
will reply. If the client will not reply then server will tear down
the IKE SA and assume the connection is broken. Again this is standard
operation that must be correctly handled by all implementations, which
means it should be tested by the QA already (hopefully part of their
automatic testing suite). 

> In this case, the client would waste a packet and IPsec processing
> time on this packet, and the client cannot connect to the correct
> server as soon as possible. This is not good especially when there
> is existing session between the client and the correct server.

As the server most likely already responded with the NO_ADDITIONAL_SAS
error during the IKE_AUTH, the server and client do not have IPsec SA
between them. They only have IKE SA. And the exactly same delay will
happen if the packet containing N(REDIRECT) is lost, regardless
whether it is part of the IKE_AUTH or INFORMATIONAL exchange.

> case, if the REDIRECT payload is received before the last AUTH
> message (i.e. reordering), the client shoudl reject it.

Yes.

> Then the
> sqerver would have to send another REDIRECT payload to the client
> again after it realizes that the client is not redirected yet,
> right? Thanks.

It will resend the packet containing the N(REDIRECT) notify when it
realizeds it has not received reply packet for that. Meaning it will
resend it after 0.5-1 second or so.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 19:15:04 +0200

> that it would make the whole client thing more sensible.

Or just remove the "connect" button, as it is not needed... And do not
even allow things like per port SAs, as those are not needed either
:-)

(Yes, we do support per-host, port-protocol, per-port SAs mostly
because our QA would kill us if we removed them, as they are very
useful in the stress testing, i.e. like creating thousands SAs with
very few machines. On the other hand there is not usually that good
reasons for using them in real world, and they actually weaken the
security as they allow much easier traffic flow tracking than wider
SAs).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Dec 2008 23:34:37 +0200

> even allow things like per port SAs, as those are not needed either

I agree with that, but after 10 years of trying, our customers still  
refuse to see the light and use certificates, and insist on using  
things like SecurID. They really hated it when we didn't have a  
"Connect" button and all of a sudden an authentication dialog box  
popped up and asked for the tokencode.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Dec 2008 14:36:17 -0500

>security as they allow much easier traffic flow tracking than wider

Tero,

A few years ago some of my colleagues at BBN showed (through analysis 
of real traffic flows) that per-port SAs do not really offer better 
traffic flow confidentiality than coarser grained SAs. A per-port SA 
(or an SA that accommodates an enumerated set of ports) is useful 
when one wants crypto enforcement of per-port access controls.

Steve

---

From: Dan McDonald <[email-masked]>
Date: Mon, 8 Dec 2008 16:52:03 -0500

On Mon, Dec 08, 2008 at 02:36:17PM -0500, Stephen Kent wrote:
<SNIP!>
> A few years ago some of my colleagues at BBN showed (through analysis of 
> real traffic flows) that per-port SAs do not really offer better traffic 
> flow confidentiality than coarser grained SAs. A per-port SA (or an SA that 
> accommodates an enumerated set of ports) is useful when one wants crypto 
> enforcement of per-port access controls.

OTOH, It's useful if your networking hardware has receive-rings which key off
of the offset where TCP/UDP ports live AND where the IPsec SPI lives.

If I have SAs per flow, I can have my 10Gig hardware demux them to different
CPU cores.  If my cores have dedicated crypto units... well, you see where
this is going.  :)

Dan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 9 Dec 2008 17:10:20 -0800

Hi Fan,

> I do not see they are two different methods for the same purpose.

This is an artificial demarcation. There is nothing wrong in using the
informational REDIRECT exchange to re-direct the client to another
gateway based on the client's profile.

FWIW, I think think what we have in the draft currently is sufficient.
I agree with many posts on this thread that said the additional
mechanism is not required. So I will close the issue with no changes
to the document.

Vijay

---

From: "fan zhao" <[email-masked]>
Date: Wed, 10 Dec 2008 14:24:56 -0800

Hi Vijay,

Sorry I could not respond to this thread earlier.
I was moving during the last few days and have just
settled down in the new place.
Maybe the conclusion is made too earlier, since I
want to reply several recent emails.

Sincerely,
fan

---

From: "fan zhao" <[email-masked]>
Date: Wed, 10 Dec 2008 14:42:30 -0800

Hi Tero and all,

Sorry I did not reply earlier. I was moving during last few days.
After quickly going over your comments, I agree what you mentioned
are valid issues and they should be considered and addressed during
implementation. However, these issues are implementation specific,
not related to protocol design and it is feasible to address such issues
(bugs) during implementation.

Furthermore, I agree that the IPsec server can wait for the timer to
expire to detect whether the informational message with the redirect
is lost or not. However, there is still delay that could affect performance
very much. This is a flaw of design, IMHO, which means
that even though the implementation is bug-free and very efficient,
when reordering and paket loss happen, there is nothing we can do.
The performance is very important to user experience. I would like
argue that given such considerations, redirect should be enabled
during IKE_AUTH.

Sincerely,
fan

---

From: "fan zhao" <[email-masked]>
Date: Wed, 10 Dec 2008 15:53:22 -0800

Hi Tero and all,

Please see some additional clarification below.

> whether it is part of the IKE_AUTH or INFORMATIONAL exchange.

The scenario I was considering is that previously the traffic between
the client
and its peer node is forwarded through a server, called server_a, with
the IPsec
functionality. The AAA server or other back-end server stores the address of
server_a. However, the client does not set up the IPsec SA with the server_a
when using some mobility protocol (such as Proxy Mobile IPv6). Now the client
handovers to another access network where only a different mobility
protocol (such as
Mobile IPv6) is supported. Such mobility protocol requires that
traffic between the client
and its peer node to be forwarded through the IPsec tunnel between the
client and the server_a. However, the client does not have the IP address of
the server_a (since it does not need to know, with Proxy Mobile IPv6).
After performing discovery, such as DNS, the client discovers a
different server,
called server_b, and starts the IKE procedure with the server_b. Then
the server_b
realizes (e.g. during interaction with the AAA/other server) that the
client needs to
set up the SA with server_a in order to continue the current session
with the client's
peer node. Thus redirection needs to be performed.
During handover, it is important to minimize delay for network connectivity
re-establishment in order to reduce packet delay and improve performance.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Dec 2008 13:16:06 +0200

> (bugs) during implementation.

Yes, and as those implementation details must be done correctly for
the IKEv2 to be secure, there is no point of us to try to avoid such
cases with redirct messages.

> argue that given such considerations, redirect should be enabled

Regardless what we do if the IKE_AUTH reply packet is lost or if the
INFORMATIONAL exchange having the REDIRECT notify is lost, there will
be delay where we need to wait for retransmissions. It does not matter
how we do the protocol, there will still be delays if we loose
packets. Reordering does not need to cause any delay, as
implementation can handle that internally and it can simply put the
out of order packet on hold until IKE_AUTH is processed and then
continue processing the other packet.

Note, that doing the Diffie-Hellman and signature calculations twice
here usually means about same order of magnitude delay than the one
retranmission timer, thus even on those very rare cases where you have
packet loss of hitting the INFORMATIONAL exchange packet, the delay
should not really be visible to user (i.e. it should be less than one
second). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Thu, 11 Dec 2008 18:02:40 -0800

Hi Tero,

On Thu, Dec 11, 2008 at 3:16 AM, Tero Kivinen <[email-masked]> wrote:
> packets.
I agree that if the last IKE_AUTH reply message from the server is lost,
no matter whether the REDIRECT is included or not, there will be
the same amount of delay.

Nevertheless, it is possible that the last IKE_AUTH message goes through
and the informational message with the REDIRECT notify is lost. In this
case, the delay is longer than if the REDIRECT notify is included in the last
IKE_AUTH message.

> Reordering does not need to cause any delay, as
I understand this can be done to reduce the delay. However, this is
probably not a standard behavior per RCF 4306 as it just mentions that after
an IKE_SA is set up, an IKE end point can send multiple requests
if the SET_WINDOW_SIZE is received from its peer. So interoperability
between different implementations needs to be tested because
another implementation of the client may simply drop the reordered
informational message with the N(REDIRECT) and the implementation
of the server needs to prepare if that happens, it needs to re-transmit
the N(REDIRECT). Do I understand correctly?

> should not really be visible to user (i.e. it should be less than one
During handover, the delay needs to be smaller than 0.2 second; otherwise,
it is noticeable to users.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Dec 2008 16:23:03 +0200

fan zhao writes:
> if the SET_WINDOW_SIZE is received from its peer.

We are not talking about multiple requests, we are talking about one
request that arrives before the IKE_AUTH is processed. If your
environment is so delay critical that delay of 500 ms is unacceptable
for it when those specific two packets happen to arrive out of order,
then you should implement code to get rid of it.

> So interoperability between different implementations needs to be
> tested because another implementation of the client may simply drop
> the reordered informational message with the N(REDIRECT) and the
> implementation of the server needs to prepare if that happens, it
> needs to re-transmit the N(REDIRECT). Do I understand correctly?

There is no need to do interoperability testing, as both options are
completely within the specifications and complient implementations
MUST cope with both. The server always must be prepared to re-transmit
its message regardless what other end does, as the packet might also
get lost, not just get dropped.

>From servers point of view it is either so that packet was dropped and
it needed to be resent, or packet was accepted by other end (either in
order, or out of order and reordered by client) and reply was sent
back to server.

Again this is standard IKEv2, and if IKEv2 implementations do not get
their base retransmission algorithms working, then that implementation
should not be used in anywhere... 

> it is noticeable to users.

During our mobike testing, we noticed that most of the delays caused
by network because of mobility were in the order of tens of seconds,
not in order of milliseconds. For example the DHCP usually takes about
5-20 seconds to get new IP address from the new network... 0.2 seconds
is not really doable if you have round trip times of 200 ms (0.2
seconds) like I have from Finland to US...

Also most of the Phones and similar has so slow CPU that
Diffie-Hellman and the RSA signing takes close to that 0.2 seconds...
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Sun, 14 Dec 2008 12:26:05 -0800

Hi Tero,

Please see below.

On Fri, Dec 12, 2008 at 6:23 AM, Tero Kivinen <[email-masked]> wrote:
> request that arrives before the IKE_AUTH is processed.
This is exactly my point. It is not clearly specified in the RFC that
reordering of the last IKE_AUTH and sequent requests need to
be handled.

> If your
I do not know exact reasons why the RFC does not specify how to
handle the reordered AUTH message and the requests. Anyway, if it is
not required by the RFC, then some (RFC-compliant) implementation
may not support that.

> MUST cope with both.
Does RFC 4306 talk about storing the reordered request before processing
last AUTH message? Maybe I miss something.

> The server always must be prepared to re-transmit
I agree on this part.

> seconds) like I have from Finland to US...
Yes, there are many factors affecting handover delay and there are various
optimization solutions. For example, the IP configuration can be done
proactively based on the fast handover for MIPv6 protocol. While it is possible
that even with all kinds of optimizations, the handover delay is still larger
than 0.2 second, the point here I am trying to make is that we should
not make the
(already unacceptable) delay become even worse. Even though the delay caused
by packet loss/reordering is of the same order of magnitude or smaller
than other
kind of delay, I would like to argue that it is still beneficial to
avoid adding such delay.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2008 15:58:21 +0200

> reordering of the last IKE_AUTH and sequent requests need to

I disagree with you in that. The current RFC 4306 section 1 says:

          ... In all cases,

For me that clearly says that such case must be handled, it is not
left unspecified. The CREATE_CHILD_SA or INFORMATIONAL exchance MUST
NOT be processed before the IKE_AUTH is processed. Whether that is
done by dropping out of order CREATE_CHILD_SA or INFORMATIONAL
exchange packets or whether is done by holding them, and processing
IKE_AUTH first and then those packets on hold is implementation
detail, that does not affect interoperablity.

So the specification is quite clear that this case needs to be
handled. It does not propose a way how to handle it, but lets that to
be implementation detail as regardless how the implementation handles
it does not affect interoperability. 

> not required by the RFC, then some (RFC-compliant) implementation

That is fine. Reordering is not specified or required, as it does not
affect interoperability. Regardless what the other end does two peers
can still interoperate fine. We do not specify all small details for
all possible cases, quite a lot of things which do not affect
interoperability are left as in implementation details.

> last AUTH message? Maybe I miss something.

No, but it does say that all IKE_AUTH exchange MUST be finished,
before any other exchanges are allowed to be processed.

> kind of delay, I would like to argue that it is still beneficial to

You are NOT talking about the delay that happens all the time, you are
talking about the delay that MIGHT happen if packets happens to get
reordered. This is not usually that common situation and if it is
going to be common situation in your network, then it is better to get
such implementation which is specifically optimized for such
environment, and knows that packets get reordered by network most of
the time and has some specific implementation optimization that make
it work efficently even in such environments.

I think we have come very far from the original question whether we
should allow 3 different ways of doing the REDIRECT or only 2. I say 2
is enough, and I do not want to add one more complication to the
IKE_AUTH even when it would be 0.2 seconds faster in environments
where IKE_AUTH reply and first INFORMATIONAL request from server are
always reordered and the implementation used in the client end, in
such wierd environment are not optimized for such wierd environment.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Mon, 15 Dec 2008 15:29:35 -0800

Hi Tero,

Please see below.

On Mon, Dec 15, 2008 at 5:58 AM, Tero Kivinen <[email-masked]> wrote:
> detail,
Yes, that is what I meant.

> that does not affect interoperablity.
>
Fine with me. I think my point was made clear: some implementation
may simply drop reordered requests and some implementaion may
store them; both are compliant to the IKE spec.

> interoperability are left as in implementation details.
Ok, though I am wondering if the client saves the requests before finishing
processing the IKE_AUTH, does it open a window for the
Denial-of-service attack?
Because the eavesdroppers can flood the client with a lot of bogus requests,
which consumes a lot of memory at the client since the client does not
know whether they are from attackers or the server. Though the client
can control how many requests can be stored, it seems to me that this
introduces something additional to the implementation.

> reordered.
Yes, What I considered also includes the delay introduced when the
N(REDIRECT) is dropped.

> This is not usually that common situation and if it is
It is very difficult to predict/model packet loss and reordering. Even though
there are some implementaion optimization, the best way is to reduce the
probability of loss/reordering.

> such wierd environment are not optimized for such wierd environment.
Let us wrap up the discussion. Below is the summary, please feel free
to add your oponions or correct it.

N(Redirect) during IKE_AUTH
Pros:
1) less overhead, including payloads sent over the wired/wireless link and
cpu cycles/memory for additional packet processing

2) faster: no need to wait for another one way latency, i.e. transferring the
N(Redirect) from the server to the client (this delay can be smaller
e.g. if sending the N(Redirect) immediately after the IKE_AUTH)

3) reduce the probability of packet loss and reordering

Cons:
Increase complexity of implementaion, for example, more tests
Fan: it is an implementation issue and can be addressed. I
do not see such complexity can justify the sacrifice in performance.

Thanks for discussion.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Dec 2008 15:41:54 +0200

> Denial-of-service attack?

Not really. The window size is usually still at one 1 at that point
(provided there is even other implementations than ours that support
bigger windows), so the responder needs to only keep one incoming
message for optimized behavior. If the initiator has already announced
bigger window size, it might keep as many request as it announced for
its window size.

I myself would only implemet at max of one packet holdout buffer there
if I would need to really cope environments where reordering is such
big problem that I really need to optimize for it, as that one packet
buffer would be enough for the normal optimized case.

> introduces something additional to the implementation.

As complient implementation of the other end cannot send more than
window size of requests to other end, then it is best to simply limit
the buffer to that many packets. You need that kind of buffer anyways
for IKEv2, as the current specification says that you MUST keep old
packets forever for all packets that are still in the window, so this
will NOT add any new memory resources to be used.

> cpu cycles/memory for additional packet processing

And we are talking about 2 * 100 bytes (1600 µs at 1 MBit/s wireless
link) of overhead here including about 2 * 40 bytes of symmetric
encrypt/decrypt (2 * 1.1 µs (encrypt) + 2 * 1.6 µs (decrypt) for
aes-128) and 2 * 90 bytes of MACed content (2 * 8 µs for hmac-sha1-96)
so the total overhead is 21.4 µs for crypto and 1600 µs for 1Mbit/s
wireless link. To be safe we can say the overhead is less than 2 ms...

> e.g. if sending the N(Redirect) immediately after the IKE_AUTH)

There is no extra delay except for actual transmission time of that
100 byte long packet. There is no need to wait any one way latency or
round trip times. 

> do not see such complexity can justify the sacrifice in performance.

As I do not really see any pros, and there is very large cons
(complexity), I myself are clearly on the side of less complexity i.e
lets not add yet another mode to the IKE with no real benefits.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Tue, 16 Dec 2008 12:09:36 -0800

Hi Tero,

Please see below.

> buffer would be enough for the normal optimized case.
Yes, that is what I meant by saying "control how many requests can be stored".

> will NOT add any new memory resources to be used.
I think we have discussed this: what is explicitly specified in the RFC
is for sebsequent requests.

> wireless link. To be safe we can say the overhead is less than 2 ms...
The time needed for crypt operations also depends on hardware.

> 100 byte long packet. There is no need to wait any one way latency or
Yes, the delay is the actual transmission time of that 100 bytes long packet.
I am saying it is a delay because if N(REDIRECT) is included in the IKE_AUTH
message, there is no additional transmission time needed.

> lets not add yet another mode to the IKE with no real benefits.
Can you please quantify the complexity so that we can do a head-to-head
comparison? As you said before, such complexity could be due to additional
checking for bugs? It will be good if you can estimate time comsumption
for executing testing code under the same benchmark. If these bugs are
hard to predict/find, please let me know why they cannot be found and how
adding N(REDIRECT) to the IKE_AUTH message causes that?

Sincerely,
fan