Re: [IPsec] New draft posted

Tero Kivinen <> Mon, 26 April 2010 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDB943A6B9B for <>; Mon, 26 Apr 2010 05:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zEcx808JrLT2 for <>; Mon, 26 Apr 2010 05:57:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA2CF3A6922 for <>; Mon, 26 Apr 2010 05:57:24 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id o3QCuuNr020786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 15:56:56 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.3/8.12.11) id o3QCutEb025308; Mon, 26 Apr 2010 15:56:55 +0300 (EEST)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 26 Apr 2010 15:56:55 +0300
From: Tero Kivinen <>
To: Yoav Nir <>
In-Reply-To: <>
References: <> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux> <> <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 8 min
X-Total-Time: 8 min
Cc: "" <>, Jitender Arora <>
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, 26 Apr 2010 12:57:26 -0000

Yoav Nir writes:
> Actually, in our implementation, all packets (IKE and ESP) have the
> cluster IP address, so the peer doesn't notice a failover, and also
> the peer can't tell which member is "active" or which member it is
> working with. 

Yes, that is also one way doing it, but in that case there is no
problem, as IKE and ESP uses same address.

> > 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.
> Not really. The IPsec stack constructs the ESP header and
> encapsulating IP header for tunnel mode SAs. It can put whatever
> external IP address it wants in there. IKE is handled by a user
> space process that opens a regular UDP socket and sends packets. To
> get those packets to have the cluster IP address, we need some
> special OS feature that allows you to override the IP stack, or a
> NAT mechanism to change the packets. 

In userspace you can still use the normal bind operation to bind the
source IP to specific IP address. You do not need special OS features,
those features are usually present in most of the operating systems
available, so you just need standard OS features... 

> > 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.
> MOBIKE was intended for mobile clients such as laptops and phones.

That is one use.

Another use for for gateways to provide high-availability when you
have multiple connections to the internet, i.e. multiple ISPs. 

> It would be weird to use that for the enterprise gateway that uses
> clustering to improve scalability or availability.

I would expect to see it in all environments where the gateway
supports redundant intenet connections, i.e. same box has two
connections to the internet using different ISPs (and of course using
completely different IP-addresses).

> But in any case, at the moment we are only dealing with a problem
> statement. Solutions are yet to come.

I have not read the draft you mentioned, but I assumed it was also
solution document, not problem statement document. I do not know how
it relates to MOBIKE, or to anything else, but I think MOBIKE is one
of the solutions we are going to be using where it is applicable.