IETF Logo Mail Archive

Re: [IPsec] Number of fixed SPI

Daniel Migault <daniel.migault@ericsson.com> Fri, 24 March 2017 20:41 UTC

Return-Path: <daniel.migault@ericsson.com>
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 06940129981; Fri, 24 Mar 2017 13:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 yscE1N7JpQqc; Fri, 24 Mar 2017 13:41:49 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 A3204129962; Fri, 24 Mar 2017 13:41:49 -0700 (PDT)
X-AuditID: c618062d-d73ff700000009d8-3d-58d595f90654
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id DE.D1.02520.9F595D85; Fri, 24 Mar 2017 22:56:12 +0100 (CET)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Fri, 24 Mar 2017 16:41:36 -0400
From: Daniel Migault <daniel.migault@ericsson.com>
To: "Paul.Koning@dell.com" <Paul.Koning@dell.com>
CC: IPsecME WG <ipsec@ietf.org>, "lwip@ietf.org" <lwip@ietf.org>
Thread-Topic: [IPsec] Number of fixed SPI
Thread-Index: AQHSpNzABrDXwZOU10SXLftJp6gwyKGkdCyg
Date: Fri, 24 Mar 2017 20:41:28 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB6EE6@eusaamb107.ericsson.se>
References: <CADZyTkk512LR=cxOsmK_nOO3RdSi9ZVm_aXyqqMMCmSUfKO63w@mail.gmail.com> <4EF73939-B0F0-4E80-96B5-619E416D8AB6@dell.com>
In-Reply-To: <4EF73939-B0F0-4E80-96B5-619E416D8AB6@dell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPiO6fqVcjDN5tkLDYv+UFm8W8fcIW a55XODB7TJo5g9ljyZKfTAFMUVw2Kak5mWWpRfp2CVwZX17aFSwTrFj9upuxgfELbxcjJ4eE gInEgQnLmLsYuTiEBNYzSmy/288K4SxnlOh4c5oJpIpNwEii7VA/O4gtImAo8WTxE1YQm1nA QeLOsy1ANRwcwgIaElNeqkOUaEpM33uXEcI2kvi29QwLiM0ioCpx/uNusDG8Ar4Ss45sh9rV xCgx+/UssJmcAjYSHa9Ogu1lFBCT+H5qDRPELnGJW0/mM0FcLSCxZM95ZghbVOLl43+sELaS xMff89kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaO0 uCAnN93IYBMjMCaOSbDp7mC8P93zEKMAB6MSD6/BnysRQqyJZcWVuYcYJTiYlUR4H1pfjRDi TUmsrEotyo8vKs1JLT7EKM3BoiTOO+H8hQghgfTEktTs1NSC1CKYLBMHp1QDo9zmOT2q69qM Dne1+GaGHw3L3rDUzlkp0/d4vEDZ0nMzGbeX+V1wnCd8sM3xvcZZBibH0DW7382R2HUsM//p dzf3qAPvEsPT7T9aJLMsFVBRcuv3Wlfmrbxpq5kAj4n1qzr39WnsT+cyclakTPQ37epU29TU nc7sPnlKwb3TTnkOJ2a/twlVYinOSDTUYi4qTgQA5Eu+DoUCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/J3cUC-RsGgnf0B7mARkvGPTneio>
Subject: Re: [IPsec] 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: Fri, 24 Mar 2017 20:41:51 -0000

Hi Paul, 

My understanding of RFC4301 section 4.1, is that nodes supporting only unicast communications can index their SA only using the SPI while nodes supporting multicast communications must also use the IP addresses and thus SA lookup needs to be performed using the longest match.

I guess that multipurpose interoperability is achieved with the longest match lookup. But I agree I am also confused. 

Yours, 
Daniel


-----Original Message-----
From: Paul.Koning@dell.com [mailto:Paul.Koning@dell.com] 
Sent: Friday, March 24, 2017 4:25 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Subject: Re: [IPsec] Number of fixed SPI


> On Mar 24, 2017, at 4:16 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
> 
> Hi, 
> 
> I have a question regarding devices that are not able to randomly generate SPI, but instead store fix values.  The question is how much fix values could be provisioned. 
> 
> 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. 

I must be missing something.  Maybe I'm remembering older documents.  My understanding of ESP and the security architecture RFC is that lookup is required to be by SPI and IP address.

Where do you see text that suggests SPI-only lookup is compliant?

A principle of communication standards design is that conformance should imply interoperability, so if the RFC really does permit one node to send something that another node would not be able to handle, that would be an RFC bug.

	paul

v2.23.0 | Report a Bug | By Email