Re: [IPsec] New draft posted

Tero Kivinen <kivinen@iki.fi> Mon, 03 May 2010 12:40 UTC

Return-Path: <kivinen@iki.fi>
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 8E6AC3A6C66 for <ipsec@core3.amsl.com>; Mon, 3 May 2010 05:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.732
X-Spam-Level:
X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_50=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 ah7kuC1-IDIx for <ipsec@core3.amsl.com>; Mon, 3 May 2010 05:40:05 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7490E3A6CA9 for <ipsec@ietf.org>; Mon, 3 May 2010 05:39:59 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o43CdYFj006711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 15:39:34 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o43CdXXK026740; Mon, 3 May 2010 15:39:33 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19422.50181.199229.35876@fireball.kivinen.iki.fi>
Date: Mon, 3 May 2010 15:39:33 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Jitender Arora <JArora@acmepacket.com>
In-Reply-To: <A8F897BE25922348AB562D74E6C686E41F48A87A8E@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>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 13 min
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: Mon, 03 May 2010 12:40:08 -0000

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)

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.

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.

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).

>     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. 
-- 
kivinen@iki.fi