Re: [Lwip] Number of fixed SPI

Daniel Migault <daniel.migault@ericsson.com> Wed, 29 March 2017 03:49 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26D5128D3E; Tue, 28 Mar 2017 20:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsolTJtcvntf; Tue, 28 Mar 2017 20:49:46 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359B7127058; Tue, 28 Mar 2017 20:49:46 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id y18so43914982itc.1; Tue, 28 Mar 2017 20:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CWkd6cums51+gRxINd/IXGGVMNf9sH9/tDNxS3VSqKs=; b=e2Bq9QIlcWxPUDR2iFzQlaq65eK2gGlIWT+OzWpndGAECWf6UwfMfaYCTicZFGNKRo nETaB6K8LW5UiDpPn/kBvqASfVis+tcsT7jwzJTIr6gLo4+6bD/VeTKr2DiDQPIHk0+p 96vRUvSgBFfAAqSl41Y2ssGXllly/dOESu0oAo45L4NTWY/EWmN0BgeMGNN0/ExNyn/g 2noZAHqXNfXQtQYfiO457XfGZWmML9mP82hp9ZmnARGlBaCV5whlb/r3T3AFKB9HTaaW btzyEZDYq3Li81RCQmd3/KnMXmR0FI+C1QMiQ/o0Mbbu7MRO4pyviTdjN1LPXNUuhj7T zZsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CWkd6cums51+gRxINd/IXGGVMNf9sH9/tDNxS3VSqKs=; b=jM+jSH2HNuC5f5IzCotODcpNmJDzb9hY4loYC7LAarNUSSFSExeWWOodiKVk/r1eDi XVQEvfiawEMGwD2Fn0c1PkzYMYwugGONTGiwWOlxNNu+k3b5afaxdw5EpBaLTUeYh2xG RgaPSRlkJo2aHbFuAahHqAdJHAtvGUnlurGJauMVMXIxWREkDa9JsU5LtqtMKCTCZbPq WqV+HjS8Rhr0Q2BKW7/XcqIEIAxYxdI1u8IbwjnYjsRbnyaRS7NWE/c3Mu2+ypFGPwyh dzi/qeTB6ZCwxzA4i86mdNIqqTBdtT1pyZZuW68HCZK1rLYQFsnjB3Em9HcVHEgCHbgE nFpw==
X-Gm-Message-State: AFeK/H3ZSTWdx5VluN/RdnmeyvnPlMYrlyZlBwq1wbT+kR6oMMrsQTuDS5XovPXpRwgY9YBZmGEQsuBSMHDrSw==
X-Received: by 10.107.168.21 with SMTP id r21mr29006593ioe.45.1490759385664; Tue, 28 Mar 2017 20:49:45 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.35.213 with HTTP; Tue, 28 Mar 2017 20:49:45 -0700 (PDT)
In-Reply-To: <22744.3148.820880.102484@fireball.acr.fi>
References: <CADZyTkk512LR=cxOsmK_nOO3RdSi9ZVm_aXyqqMMCmSUfKO63w@mail.gmail.com> <22744.3148.820880.102484@fireball.acr.fi>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 28 Mar 2017 22:49:45 -0500
X-Google-Sender-Auth: u2rz2Js_vcQXIor4so0AisDF2TY
Message-ID: <CADZyTknNt1vvqfBQuA11m6fktfzjfsvHwPgEY4QKe+uyK306uw@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: IPsecME WG <ipsec@ietf.org>, "lwip@ietf.org" <lwip@ietf.org>
Content-Type: multipart/alternative; boundary="001a114215e8a0d237054bd67711"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/QvjdfZf-4dPnEBO35WOvY0mxLnc>
Subject: Re: [Lwip] Number of fixed SPI
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 03:49:49 -0000

Thank you for the clarification. My initial problem was if multiple nodes
connects with the same SPI to a gateway, does the gateway needs some
specific ways to lookup. As mentioned by Tero, this is not the case as the
SPI is not used for inbound traffic by the gateway. The limitation due to a
limited number of SPI are on the node side.Thanks!

On Sun, Mar 26, 2017 at 1:45 PM, Tero Kivinen <kivinen@iki.fi> wrote:

> Daniel Migault writes:
> > For unicast communications, a single SPI can be used over multiple
> > nodes as long as the remote peer, as long as both nodes uses IP
> > addresses and SPI to index the SAs. With the transport mode, the
> > number of SPI is equivalent to the number of hosts, while with
> > tunnel mode, the number of SPI is equivalent to the number of
> > tunnels.  For that reason I would recommend that a minimal
> > implementation supporting unicast only has as many SPI values as ESP
> > session per host or per security gateways, and that lookup includes
> > the IP addresses.
> >
> > However this would not work with a security gateway that performs
> > lookup only based on the SPI. Such security gateway would still be
> > ESP.compliant. Does it sounds reasonable that security gateways
> > implements the longest match lookup or at least lookup considering
> > IP addresses ?
>
> ESP SPI is allocated by the receiving host. It is up to the node
> receiving the ESP packets with SPI it gave out to decide how the SPI
> is allocated, and used.
>
> The sender can have multiple SAs going out each having same outbound
> SPI, and that does not cause any issues. The receiver will either have
> unique SPI for each Child SA, or it might use SPI with combination of
> the protocol number (AH or ESP), or it might even use the destination
> address (i.e., its own address or multicast address) etc.
>
> But there is no issues in there, as the node who does the receiving
> is also the same node who allocates the SPIs, so he can enforce his
> own rules on the SPI allocatons, and the other end does not need to
> know those rules.
> --
> kivinen@iki.fi
>
> _______________________________________________
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>