[IPsec] [Lwip] Number of fixed SPI

Tero Kivinen <kivinen@iki.fi> Sun, 26 March 2017 18:45 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0801612785F; Sun, 26 Mar 2017 11:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 AAY-rXB14l2j; Sun, 26 Mar 2017 11:45:39 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB119124217; Sun, 26 Mar 2017 11:45:38 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2QIjYWO021384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Mar 2017 21:45:34 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2QIjWUk012321; Sun, 26 Mar 2017 21:45:32 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <22744.3148.820880.102484@fireball.acr.fi>
Date: Sun, 26 Mar 2017 21:45:32 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: "lwip@ietf.org" <lwip@ietf.org>, IPsecME WG <ipsec@ietf.org>
In-Reply-To: <CADZyTkk512LR=cxOsmK_nOO3RdSi9ZVm_aXyqqMMCmSUfKO63w@mail.gmail.com>
References: <CADZyTkk512LR=cxOsmK_nOO3RdSi9ZVm_aXyqqMMCmSUfKO63w@mail.gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 6 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ZixpaA2t9xhsR0-O8rEjR36YQSY>
Subject: [IPsec] [Lwip] Number of fixed SPI
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Sun, 26 Mar 2017 18:45:41 -0000

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