Re: [IPsec] New draft posted

Tero Kivinen <kivinen@iki.fi> Mon, 26 April 2010 11:29 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 45F623A6984 for <ipsec@core3.amsl.com>; Mon, 26 Apr 2010 04:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599]
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 t9mghGJexX0f for <ipsec@core3.amsl.com>; Mon, 26 Apr 2010 04:29:55 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E6C3D3A6B81 for <ipsec@ietf.org>; Mon, 26 Apr 2010 04:29:40 -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 o3QBTGNe021683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 14:29:16 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3QBTFWc014492; Mon, 26 Apr 2010 14:29:15 +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: <19413.30987.504756.15413@fireball.kivinen.iki.fi>
Date: Mon, 26 Apr 2010 14:29:15 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <FDE82F7F-9D87-4AAF-9496-90F28F36976E@checkpoint.com>
References: <ea322d4c93b67735a8e6eb26cc9fca41.squirrel@www.trepanning.net> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux> <FDE82F7F-9D87-4AAF-9496-90F28F36976E@checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 5 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Jitender Arora <JArora@acmepacket.com>
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, 26 Apr 2010 11:29:56 -0000

Yoav Nir writes:
> I agree. And whatever we may think of the particular solution, it does present a problem that can and should be in the problem statement draft.
> 
> So how about adding teh following sub-section:
> 
> 3.7.  Different IP addresses for IKE and IPsec
> 
>    In many implementations there are separate IP addresses for the
>    cluster, and for each member.  While the packets protected by tunnel
>    mode child SAs are encapsulated in IP headers with the cluster IP
>    address, the IKE packets originate from a specific member, and carry
>    that member's IP address.  For the peer, this looks weird, as the
>    usual thing is for the IPsec packets to come from the same IP address
>    as the IKE packets.

Normally all ESP packets also have the members IP address as their
outer address, so there is no problem. Both IKE and ESP packets have
same address (provided the IKE and Child SAs are located on the same
cluster member).

If the ESP packets have special handling that will change their outer
source address to match cluster's IP address instead of individual
member's IP address, then the same mechanims can easily be used for
IKE SA too.

>    One obvious solution, is to use some fancy capability of the IKE host
>    to change things so that IKE packets also come out of the cluster IP
>    address.  This can be achieved through NAT or through assigning
>    multiple addresses to interfaces.  This is not, however, possible for
>    all implementations.

I would expect this to be one of those very basic systems provided by
the cluster, so if cluster implementationdoes not offer such setup,
then it most likely does not offer that for Child SAs either, thus
there is no problem, as both ESP and IKE will use same IP (i.e.
member's own IP). 

We already have standard track mechanims for updating the outer
address for both Child SAs and IKE (MOBIKE), so even when the
cluster's outer IP address is used in normal case, the failover to
another cluster member (using different IP address) is easy to do
provided both the cluster member's share the same SA state.
-- 
kivinen@iki.fi