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

Stephen Kent <kent@bbn.com> Thu, 27 May 2010 14:30 UTC

Return-Path: <kent@bbn.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 51BD83A6B01 for <ipsec@core3.amsl.com>; Thu, 27 May 2010 07:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 h8CgsyIecM6Z for <ipsec@core3.amsl.com>; Thu, 27 May 2010 07:30:51 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6595A3A6B00 for <ipsec@ietf.org>; Thu, 27 May 2010 07:30:51 -0700 (PDT)
Received: from dhcp89-089-244.bbn.com ([128.89.89.244]:49199 helo=[128.89.89.144]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1OHe6a-000IQE-Hj; Thu, 27 May 2010 10:30:40 -0400
Mime-Version: 1.0
Message-Id: <p06240816c8242e8cacfc@[128.89.89.144]>
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 10:18:23 -0400
To: Yoav Nir <ynir@checkpoint.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 14:30:52 -0000

At 11:36 AM +0300 5/27/10, Yoav Nir wrote:
>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.
>
>Yoav

The text above seems rather indirect. How about:

3.8  Allocation of SPIs
    The SPI associated with each child SA, and with each IKE SA, MUST be
    unique relative to the peer of the SA.  Thus, in the context of a
    cluster, each cluster member MUST generate SPIs in a fashion that
    avoids collisions (with other cluster members) for these SPI values.
    The means by which cluster members achieve this requirement is a local
    matter, outside the scope of this document.


Steve