Re: [IPsec] New draft posted

Yoav Nir <> Sun, 25 April 2010 11:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BA233A69DD for <>; Sun, 25 Apr 2010 04:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.752
X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HE0deypfHF2G for <>; Sun, 25 Apr 2010 04:34:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF8863A69D2 for <>; Sun, 25 Apr 2010 04:34:30 -0700 (PDT)
Received: from ( []) by (8.12.10+Sun/8.12.10) with ESMTP id o3PBYEph014278; Sun, 25 Apr 2010 14:34:14 +0300 (IDT)
X-CheckPoint: {4BD4367C-0-1B201DC2-2FFFF}
Received: from ([]) by ([]) with mapi; Sun, 25 Apr 2010 14:34:44 +0300
From: Yoav Nir <>
To: Yaron Sheffer <>
Date: Sun, 25 Apr 2010 14:34:16 +0300
Thread-Topic: [IPsec] New draft posted
Thread-Index: Acrka0zx6TC9ptA2SPCGubX2McRa3w==
Message-ID: <>
References: <> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux>
In-Reply-To: <1272187315.22380.46.camel@yaronf-linux>
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
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: Sun, 25 Apr 2010 11:34:32 -0000

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.

   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.

   [ARORA] discusses this problem in greater depth, and proposes another
   solution, that does involve protocol changes.

On Apr 25, 2010, at 12:21 PM, Yaron Sheffer wrote:

> Hi Jitender,
> this is certainly an interesting approach to the
> high-availability/load-balancing issue that we are just starting to
> tackle, as a group. I would appreciate your inputs to the discussion on
> draft-ietf-ipsecme-ipsec-ha.
> Below are a few initial comments on your draft:
> - I suggest moving Sec. 5.1 to the front (or at least pointing to it
> from the Introduction) so that the motivation becomes clear before the
> protocol details are presented.
> - Of course, if there are additional usage scenarios, it would be nice
> to include them.
> - Essentially ignoring the issue of NAT severely hurts the applicability
> of this protocol. Even saying something like "use STUN/TURN" is better
> than limiting the protocol to closed networks.
> - The security considerations never discuss the issue that the peer can
> now claims ownership of ANY IP address. I *think* this is just a
> denial-of-service issue, but it certainly needs to be analyzed. Which
> leads to the main issue with this proposal:
> - This is not just a change to IKEv2, it is a rather major change to the
> IPsec architecture. So I would expect some discussion of RFC 4301
> entities. See the last 2 paragraphs of
> for an example.
> Thanks,
> 	Yaron
> On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote:
>> Hi All,
>> A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt has been posted to the IETF repository.
>> Filename:	 draft-arora-ipsecme-ikev2-alt-tunnel-addresses
>> Revision:	 00
>> Title:		 Alternate Tunnel Addresses for IKEv2
>> Please take a look and comment.
>> Regards,
>> Jitender
>> _______________________________________________
>> IPsec mailing list
> _______________________________________________
> IPsec mailing list
> Scanned by Check Point Total Security Gateway.