Re: [IPsec] New draft posted

Tero Kivinen <kivinen@iki.fi> Wed, 12 May 2010 11:41 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 81E053A6AA6 for <ipsec@core3.amsl.com>; Wed, 12 May 2010 04:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.538
X-Spam-Level:
X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=0.001, SARE_MILLIONSOF=0.315]
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 y8hqQbC2GOti for <ipsec@core3.amsl.com>; Wed, 12 May 2010 04:41:42 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4828E3A6892 for <ipsec@ietf.org>; Wed, 12 May 2010 04:41:41 -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 o4CBfOY8016290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 14:41:24 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o4CBfNbY006180; Wed, 12 May 2010 14:41:23 +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: <19434.37859.216575.687495@fireball.kivinen.iki.fi>
Date: Wed, 12 May 2010 14:41:23 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Jitender Arora <JArora@acmepacket.com>
In-Reply-To: <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> <A8F897BE25922348AB562D74E6C686E41F48B2970E@mail>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 39 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, 12 May 2010 11:41:43 -0000

Jitender Arora writes:
> 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.

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.

Also there is no need that the load balancer itself needs to be acting
as application gateway, the published IP address for the IKEv2
connections can also be some other IP-address, i.e. that host does not
need to be on the path of the real traffic. If this one host is only
parsing IKE_SA_INIT packets and sending redirect backs any old 386 box
you can find from your junk pile will be able to handle the traffic up
to millions of clients (million clients, each connecting for example
once per hour means there is 277 connection attempts per second, and
any old box can receive 277 udp packets and send 277 udp replies back
(in completely stateless manner)). 

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

Those extra messages only happen during the setup phase, and I would
expect the load balancer can pass through those less than 300 messages
per second. If it cannot, then you have much bigger problems when the
real traffic starts to come in... 

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

So if the load balancer cannot handle few hundred packets per second
to passthrough then I think you should really consider replacing the
hardware.

For normal IPsec use the IKEv2 packet are not send periodically at
all. There is 2+2 packets in the beginning. There might be one DPD
exchange over IKEv2 SA when the ESP traffic stops, but after that
there shouldn't be anything until the ESP traffic restarts.

So there should very little IKEv2 traffic, and in normal case it is
limited to about 6 packets in total over the whole lifetime of the
IKEv2 SA.

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

http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html
-- 
kivinen@iki.fi