Re: [IPsec] New draft posted

Jitender Arora <JArora@acmepacket.com> Mon, 03 May 2010 03:29 UTC

Return-Path: <JArora@acmepacket.com>
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 DCDA33A6BBA for <ipsec@core3.amsl.com>; Sun, 2 May 2010 20:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.927
X-Spam-Level:
X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 yhq2qjEOQM3F for <ipsec@core3.amsl.com>; Sun, 2 May 2010 20:29:48 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D4B013A6B91 for <ipsec@ietf.org>; Sun, 2 May 2010 20:29:47 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 2 May 2010 23:29:32 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 2 May 2010 23:29:32 -0400
From: Jitender Arora <JArora@acmepacket.com>
To: Tero Kivinen <kivinen@iki.fi>
Date: Sun, 2 May 2010 23:29:30 -0400
Thread-Topic: [IPsec] New draft posted
Thread-Index: Acrl/usPMO3jVKKvQdC+CdfIL5IzqQEbxT39
Message-ID: <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>
In-Reply-To: <19414.51287.786283.875147@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 03:29:49 -0000

Hi Tero,

    Thanks for your feedback.

    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.

    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.

    Hope this helps, Please let me know what you think.

Thanks,
Jitender
________________________________________
From: Tero Kivinen [kivinen@iki.fi]
Sent: Tuesday, April 27, 2010 7:19 AM
To: Jitender Arora
Cc: Yaron Sheffer; ipsec@ietf.org
Subject: Re: [IPsec] New draft posted

Jitender Arora writes:
> 1.  I will point the section 5.1 in the introduction itself that way
> the purpose and applications of the draft are clear.

After I read the section 5.1 (I skipped most of the other draft as I
needed to know first WHY this is needed before I care about HOW it is
implemented), and I do not really see enough text there to cause me to
read the HOW part.

So I would need better and more text about WHY this extension is
needed. Why it is important that the IKEv2 SA and Child SA uses
different outer addresses? Who is supposed to terminate the IKEv2 SA
and who is supposed to terminate the Child SAs. Is this assuming that
IKEv2 SA and Child SA are still on the same machine or what? If so,
why not just use the IP address of that host for both IKEv2 SA and
Child SA?

So I think the usage scenarios (WHY part) is much more important than
the actual protocol (HOW part), and it should be clear from the
beginning.

Currently this draft mostly assumes there is problem, but it does not
explain why you think the problem actually exists or what the problem
is.
--
kivinen@iki.fi