[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
- [IPsec] Number of fixed SPI Daniel Migault
- Re: [IPsec] Number of fixed SPI Daniel Migault
- Re: [IPsec] Number of fixed SPI Paul Wouters
- Re: [IPsec] Number of fixed SPI Paul Wouters
- [IPsec] [Lwip] Number of fixed SPI Tero Kivinen
- Re: [IPsec] [Lwip] Number of fixed SPI Daniel Migault