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
- [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 SeongHan Shin
- 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