Re: [IPsec] New draft posted

Tero Kivinen <kivinen@iki.fi> Wed, 19 May 2010 13:05 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 EF7423A6994 for <ipsec@core3.amsl.com>; Wed, 19 May 2010 06:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.646
X-Spam-Level:
X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.647, 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 MZGVvKzyLLpf for <ipsec@core3.amsl.com>; Wed, 19 May 2010 06:05:41 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id ED3563A6971 for <ipsec@ietf.org>; Wed, 19 May 2010 06:05:05 -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 o4JD4pQT009207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 16:04:51 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o4JD4pvt024955; Wed, 19 May 2010 16:04:51 +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: <19443.57842.994830.910355@fireball.kivinen.iki.fi>
Date: Wed, 19 May 2010 16:04:50 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Jitender Arora <JArora@acmepacket.com>
In-Reply-To: <A8F897BE25922348AB562D74E6C686E41F5835E6BD@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> <A8F897BE25922348AB562D74E6C686E41F48B2970E@mail> <19434.37859.216575.687495@fireball.kivinen.iki.fi> <A8F897BE25922348AB562D74E6C686E41F5835E6BD@mail>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 15 min
X-Total-Time: 14 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: Wed, 19 May 2010 13:05:43 -0000

Jitender Arora writes:
> Load balancer by definition needs to know the devices where it is
> sharing the load to, so I do not consider that a problem. Also if the
> redirection is done in the IKE_SA_INIT phase then the application
> support required is very minimal.
> 
> 
> Jitender--> Adding the IKEv2 stack on the Load balancer defeats the
> purpose of having a generic load balancer, which can work for any
> type of sessions. For example in our case we will be load balancing
> the SIP traffic, IPSEC tunnels and will add more types of
> applications. So this box is not going to handle only the load
> balancing of the IPSEC tunnels. Most of the vendors would like the
> load balancer to be generic and not application dependent.

So you have generic load balancer, which doesn't want to know anything
about the protocols, but then you are adding more and more types of
application to be handled by the same load balancer. This is bit of
a contradiction.

Your generic load balancer support can easily be so that it forwards
all IKEv2 and IPsec traffic destinationed directly to the security
gateways to those gateways (or the router will already take care of
that if you do not want to route packets through load balancer), and
when new IKEv2 connection comes in with the published IP-address you
either process that in the load balancer, or forward it to any of the
security gateways (or one master security gateway) which will then do
IKEv2 redirect to proper gateway.

I still do not see any need for why the IKEv2 in the load balancer
should support your extended IKEv2 protocol, when it can implement the
normal redirect protocol and redirect the whole IPsec and IKEv2 SA
combo to suitable gateway.

In your proposal who is terminating the IKEv2 connections? Who is
sending the N(TUNNEL_ADDRESS) payloads? Who is processing the IPsec
traffic?

> Jitender--> You are assuming that the Load Balancer will just be
> handling the IKE_SA_INITS, but in reality it will be communicating
> with all the security gateways also to get real time information
> about the number of sessions on each security gateway, CPU usage and
> all other matrix which will help in deciding where the new tunnel
> will be redirected.

Yes, but that protocol is outside the scope of this discussion, or at
least that is what I assumed, as your draft does not cover any of
that. The load balancer does NOT need to process any IPsec or IKEv2
packets after the initial IKE_SA_INIT to do that. It just needs to get
some statistics and other information from gateways so it can make
sure it forwards next incoming connection to suitable free sgw.

It can also provide information to the SGWs when they should move some
IPsec/IKEv2 SAs to some other SGW when one of them is getting too
loaded. The SGW can do that using MOBIKE, provided they first use some
other protocol and sync the IPsec and IKEv2 state between the old and
new SGWs. 

> So there will be much more activity going on the
> laod balance than just handling 277 connection attempts per sec. I
> would think that we don't need to go into the design discussions as
> to whether this is feasible or not. What we are proposing is the
> cleaner way of handling the load balancing issues. 

I do not think it is cleaner way, as I think it makes things very
messy if the IKEv2 and IPsec SAs are terminated in different
locations. The IKEv2 do have all kind of implicit assumptions about
the IKEv2 and IPsec address connection, and implementations have even
more. We noticed this when we were making MOBIKE, and there things
were easy as we knew that all the IP-addresses are still talking to
the same node. In your case this would not be true, and that makes
things even more complicated.

> Jitender---> I did not get this, as I said all the IKEv2 signaling
> will pass through the Load balancer. What we don't want is the IPSEC
> traffic from 2 million clients to pass through the Load balancer.

Why do the IKEv2 signaling need to pass through the load balancer? Why
it cannot go directly to the suitable SGW after the initial
IKE_SA_INIT redirect?
-- 
kivinen@iki.fi