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
- Re: [IPsec] New PAKE Criteria draft posted SeongHan Shin
- [IPsec] New PAKE Criteria draft posted Yaron Sheffer
- Re: [IPsec] New PAKE Criteria draft posted SeongHan Shin
- Re: [IPsec] New PAKE Criteria draft posted Yaron Sheffer
- Re: [IPsec] New PAKE Criteria draft posted Yaron Sheffer
- Re: [IPsec] New PAKE Criteria draft posted Yaron Sheffer
- [IPsec] New PAKE Criteria draft posted Dan Harkins
- [IPsec] New draft posted Jitender Arora
- Re: [IPsec] New PAKE Criteria draft posted Yaron Sheffer
- Re: [IPsec] New draft posted Yaron Sheffer
- Re: [IPsec] New draft posted Yoav Nir
- Re: [IPsec] New draft posted Tero Kivinen
- Re: [IPsec] New draft posted Yoav Nir
- Re: [IPsec] New draft posted Tero Kivinen
- Re: [IPsec] New draft posted Jitender Arora
- Re: [IPsec] New draft posted Tero Kivinen
- Re: [IPsec] New draft posted Yaron Sheffer
- Re: [IPsec] New draft posted Yoav Nir
- Re: [IPsec] New draft posted Jitender Arora
- Re: [IPsec] New draft posted Pasi.Eronen
- Re: [IPsec] New draft posted Tero Kivinen
- Re: [IPsec] New draft posted Jitender Arora
- Re: [IPsec] New draft posted Tero Kivinen
- Re: [IPsec] New draft posted Jitender Arora
- Re: [IPsec] New draft posted Tero Kivinen