Re: [IPsec] New draft posted

Jitender Arora <JArora@acmepacket.com> Wed, 05 May 2010 02:05 UTC

Return-Path: <JArora@acmepacket.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FF73A6993 for <ipsec@core3.amsl.com>; Tue, 4 May 2010 19:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.617
X-Spam-Level:
X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckBBVT7EIfEw for <ipsec@core3.amsl.com>; Tue, 4 May 2010 19:04:58 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3DFD23A6947 for <ipsec@ietf.org>; Tue, 4 May 2010 19:04:58 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 4 May 2010 22:04:43 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 4 May 2010 22:04:40 -0400
From: Jitender Arora <JArora@acmepacket.com>
To: Tero Kivinen <kivinen@iki.fi>
Date: Tue, 4 May 2010 22:04:39 -0400
Thread-Topic: [IPsec] New draft posted
Thread-Index: AcrqvcM9m5BOqxkrTF6onzPqzFHDdABN1/ag
Message-ID: <A8F897BE25922348AB562D74E6C686E41F48B2970E@mail>
References: <ea322d4c93b67735a8e6eb26cc9fca41.squirrel@www.trepanning.net> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux> <A8F897BE25922348AB562D74E6C686E41F488DA639@mail> <19414.51287.786283.875147@fireball.kivinen.iki.fi> <A8F897BE25922348AB562D74E6C686E41F48A87A8E@mail> <19422.50181.199229.35876@fireball.kivinen.iki.fi>
In-Reply-To: <19422.50181.199229.35876@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A8F897BE25922348AB562D74E6C686E41F48B2970Email_"
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] New draft posted
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2010 02:05:00 -0000

Hi Tero,



    My comments are inline.



Thanks,

Jitender



-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Monday, May 03, 2010 8:40 AM
To: Jitender Arora
Cc: Yaron Sheffer; ipsec@ietf.org
Subject: RE: [IPsec] New draft posted



Jitender Arora writes:

>     Currently the IKEv2 does not allow the IKEv2 signaling and the

>     IPSEC traffic to go to different IP addresses, so this is the

>     problem this draft is trying to solve.

>

>     The application where it is required now is the load balancing

>     of the IPSEC tunnels. Suppose in a network there are 10

>     Security-Gateways and each of these security gateways can handle

>     200000 IPSEC tunnels using the IKEv2 signaling. Now for this

>     network if we need a load balancer device which can balance the

>     tunnels across these security gateways, this load balancer

>     device will be handling the IKEv2 signaling coming from the 10

>     *200000 clients which is 2 Million clients. In addition to

>     handling the IKEv2 signaling from these clients, this will also

>     have to handle the bidirectional IPSEC traffic between the

>     clients and security gateways. So in this case this load

>     balancing device needs to be very scalable and also high

>     performance box. This might not be practical.



The easiest way is to use already standardized IKEV2 redirect and

redirect the incoming flows from the single ip to one of those load

balancing gateways in such way that IKEv2 SA and IPsec SA are on the

same IP-address.



If the SA needs to be moved because traffic distribution changes, and

SA flows needs to be moved from one machine (IP-address) to another,

you can use already standardized MOBIKE to change the termination

point where the IKEv2 and IPsec SA flows are terminated (i.e. the

outer IP-address)



Jitender--> Currently we are using this approach (basically using the redirect and the Mobike).

This is causing the following issues:



1. If the redirect message is handled by the Load Balancer, the load balancer needs to be IKEv2 aware and also it needs to know the IP addresses of the Security Gateways for which it is responsible. This can cause the performance issues as the Load Balancer should not be application aware and should do the load balancing based on the layer 3/layer 4 information.



2. If the Load Balancer passes this IKEv2 messages directly to the security gateways using the layer 3 information, the security gateway will then have to send the redirect to the client back through the LoadBalancer and telling the client to talk to different address now. This again causes an extra message exchange to achieve the load balancing.



If you want to use same outer IP-address for all of the traffic even

that is easy to do provided the cluster members follow certain rules.

For example the SPIs (both ESP and IKEv2 SPIs) can use some bits to

indicate which of the gateways is supposed to handle them. This way

all the outer IP-addresses can be same but the load balancer in front

of the actual gaweways can very quickly use simple hardware to forward

packets to correct gateway.



Jitender--> This can simply be done based on the layer3/layer4 information, which is what we are planning to do.



I do not really understand why the load balancer should be taking care

of the IKEv2 traffic? Isn't it easier that each security gateway takes

care of the IKEv2 traffic of the IPsec SAs associated with them.



Jitender--> I think, I did not make this clear, the Load Balancer will not take care of the IKEv2 traffic, it will just pass through the IKEv2 traffic to the security gateways without handling them. But all the IKEv2 traffic will have to go through this load balancer so that the IKEv2 signaling can take place between the same addresses.



In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together,

and running them on separate machines is very complicated (We just had

long discussion about this on the list, i.e. what kind of failure

models can happen and what cannot happen).



Jitender--> If this has been captured somewhere, can you please point us to that link.



>     So to solve this problem, this draft proposes that if we can

>     allow the IPSEC traffic on the different addresses than the

>     IKEv2 signaling, the load balancer can handle only the IKEv2

>     signaling and chose the right security gateway, and this

>     security gateway can tell the client to send the IPSEC traffic

>     directly to the security gateway without going through the Load

>     Balancer.



I think mkaing single machine taking care of 2 million IKEv2

connections is going to be challenging, and it is much easier to make

ten machines taking care of 200,000 clients in addition to taking care

of the IPsec SAs associated with those clients. This way the load

balancer has very easy job to just redirect the IKEv2 clients to

suitable security gateway and then that gateway can take care of all

the traffic.



>     This way the load balancer does not need to worry

>     about the IPSEC traffic and this will not put a lot of strain on

>     these boxes.



It is possible to create system where the load balancer can very

cheaply forward packets to real gateway based on for example the IPsec

SPI (this does require coordination with the machines creating those

IPsec SAs and allocating those SPIs). Same can be used for IKE SPIs

too.



>     You are right, the IKEv2 SA and the CHILD SA will still be on

>     the same machine, but will be using the different addresses.



So it is much better to use IKEv2 redirect and MOBIKE to change both

IKEv2 SA and IPsec SA outer addresses either during the initial setup

or after that.



Jitender--> Please let me know if this makes sense.

--

kivinen@iki.fi