Re: [IPsec] New draft posted

<> Mon, 03 May 2010 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2AA03A6C38 for <>; Mon, 3 May 2010 00:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.927
X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NtBM3bueHdkr for <>; Mon, 3 May 2010 00:19:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 569EC3A6932 for <>; Mon, 3 May 2010 00:19:10 -0700 (PDT)
Received: from ( []) by (Switch-3.3.3/Switch-3.3.3) with ESMTP id o437IPAQ029109; Mon, 3 May 2010 02:18:54 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 May 2010 10:18:29 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 May 2010 10:18:10 +0300
Received: from ([]) by ([]) with mapi; Mon, 3 May 2010 09:18:09 +0200
From: <>
To: <>
Date: Mon, 3 May 2010 09:18:07 +0200
Thread-Topic: [IPsec] New draft posted
Thread-Index: Acrl/usPMO3jVKKvQdC+CdfIL5IzqQEbxT39AAhucoA=
Message-ID: <>
References: <> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux> <A8F897BE25922348AB562D74E6C686E41F488DA639@mail>, <> <A8F897BE25922348AB562D74E6C686E41F48A87A8E@mail>
In-Reply-To: <A8F897BE25922348AB562D74E6C686E41F48A87A8E@mail>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 May 2010 07:18:10.0126 (UTC) FILETIME=[C8F65EE0:01CAEA90]
X-Nokia-AV: Clean
Subject: Re: [IPsec] New draft posted
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 May 2010 07:19:12 -0000

Jitender Arora wrote:

>     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.
>     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. 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.
>     You are right, the IKEv2 SA and the CHILD SA will still be on the
> same machine, but will be using the different addresses.

If the IKEv2 SA and Child SAs are on the same box, why isn't RFC 5685
sufficient to solve this problem?

RFC 5685 doesn't support using different IP addresses for IKEv2 and
ESP/AH, but it would allow bypassing the load balancer for established
IKE SAs, precisely they way you describe. 

Best regards,