IETF Logo Mail Archive

Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03

Jean-Michel Combes <jeanmichel.combes@gmail.com> Thu, 27 May 2010 10:33 UTC

Return-Path: <jeanmichel.combes@gmail.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 A7E9D3A6870 for <ipsec@core3.amsl.com>; Thu, 27 May 2010 03:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 t7mKRrBdo7z5 for <ipsec@core3.amsl.com>; Thu, 27 May 2010 03:33:16 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9E80C3A6839 for <ipsec@ietf.org>; Thu, 27 May 2010 03:33:15 -0700 (PDT)
Received: by wwb13 with SMTP id 13so50670wwb.31 for <ipsec@ietf.org>; Thu, 27 May 2010 03:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MElG+FGnWTqgBf0BGzRd/TB8nhg08RxeMvvibtIO9iE=; b=JMsP1VpI01IY3zdEq/uouA0yhQJa/Csd1ya1gMs6P9USKXJQYTBRqvddVWdN6wS2hX bPLC+QzhqqU/SRAq8ADeXRbMCBhOsxLCVdU5jzeOqumFttLtQGbvN3lPeDOBnSKEPVUj DN5gDfIk9oC2EqACCUCBkYiOdT8Qf0iUdAeFQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ezKhK49n4LQ0AuH+2qjqReQoMfkwZkH8xpUNNlbOm7AAAGoap9ffyXUS+Fs4fI/Df8 fFeY2frwu/PJWQ0UqwVsb3gqJzC4NPLtWR51aYjYXhPBZCzBSV/mlscwdBu1+vTsAU3T a/k0927ohOJ+xmfh5nZXrsnKI8dOTYc10LumM=
MIME-Version: 1.0
Received: by 10.216.165.75 with SMTP id d53mr493530wel.76.1274956379741; Thu, 27 May 2010 03:32:59 -0700 (PDT)
Received: by 10.216.161.72 with HTTP; Thu, 27 May 2010 03:32:59 -0700 (PDT)
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com>
References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> <AANLkTikiJZgUdIoM7N-34hfX8dxk6SCaJ_Sczsacknq9@mail.gmail.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com>
Date: Thu, 27 May 2010 12:32:59 +0200
Message-ID: <AANLkTinq2yXPW2hMbrCRpCLlbCkh8WrDdGVzIIQBMcAh@mail.gmail.com>
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03
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: Thu, 27 May 2010 10:33:16 -0000

Hi again,

2010/5/27 Yoav Nir <ynir@checkpoint.com>:
> How about the following text?
>
> 3.8  Allocation of SPIs
>   SPIs for child and IKE SAs MUST be unique with the same peer. However, in
>   a cluster, both members may create SAs and assign SPIs to them, so a
>   collision is possible. We believe that peers should not be required to
>   accept duplicate SPIs for different SAs, and that this needs to be
>   prevented by the cluster members by some out-of-scope method.

It's fine for me.

Best regards.

JMC.

>
> Yoav
>
> -----Original Message-----
> <snip/>
>
> 3.  The Problem Statement
>
> <JMC>
> I didn't see anything about potential collisions (e.g. SPI for a
> specific SA on a member of the cluster is already used on another
> member) during a failover: is such an issue out of scope?
> <JMC>
>
> <snip/>
>

v2.23.0 | Report a Bug | By Email