[Lwip] Number of fixed SPI

Daniel Migault <daniel.migault@ericsson.com> Fri, 24 March 2017 20:16 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 67B4C12986E; Fri, 24 Mar 2017 13:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 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] 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 Y_Z6XxPEUed7; Fri, 24 Mar 2017 13:16:48 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 9748B129473; Fri, 24 Mar 2017 13:16:48 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id 190so1096544itm.0; Fri, 24 Mar 2017 13:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=TORAk6Sld8EeLP2oo6TPc/Uq+BYh4X7VbiaNK9+rwsc=; b=nhvVAQx0Pzwx5SiLTtfS8R26vkQzngNOnOeRdAHMVEcndZCBcTZfYofH11aGEBYhnK RIeCjZ6RTDu4t2MzWXFAfotaB4m2SUMB3PsnPIeJTB4JMh9rf10em1xtsuzPfocAdbxk D5p476+K9CqEP5P2Chaf+TfA9MFVM3sdSgoInQyCeBSjjSJIKaeFWeoTMRKNJ5ZbXsdF AHcBMNBtSGrjr7wKaXf9plvw4xt07bizbdJoDgQPJwfc7wJEbyLDj3G8dOVKlKevypek tT67jh7BInt7tJnah3EriKwwiPTJq902bEhMCz397Py+xArv6xQJuDa0wwUCpoLsIU1x HLog==
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:from:date:message-id:subject :to; bh=TORAk6Sld8EeLP2oo6TPc/Uq+BYh4X7VbiaNK9+rwsc=; b=PBbm3Q/qh3iwUF0a54XHO/k8kBpzXniXyO037xfNO8i1cCuS7uxPCNDrD0dE/iJ6w/ aF/2HzHc0BsByOu224qmi7jNxgq2tn1xq/ByT7zqzSWkgHySMvtMRg3Rkr0gk1vqPjhY ZruR0Ks7J41nnQZHefln5lFUt3DmFhX9lpjg+kE17+OV+XprSTyuMSdInS2eJjRlD9eG uZXL0Mc1Hv2yDxOug9Lfe488tkuh1g627DRkpzGoScrlTbIb1qDA0uXkJj8f50potnBe b6B0vfvK+tAHQDNjxF1gWqTer/8xRRuzHpCZVCjQst0Vk+cmasVGQSA1fKTuLdjTtR3O bJ+A==
X-Gm-Message-State: AFeK/H1ltYAQF1yv1eE7ZU9caHiO7TP10UXyV0lRFpdD+EVPH2BURbRPR+1dUPHABnL/G6gAZA4owYXDaxncaQ==
X-Received: by 10.107.174.27 with SMTP id x27mr9908197ioe.35.1490386607755; Fri, 24 Mar 2017 13:16:47 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.35.213 with HTTP; Fri, 24 Mar 2017 13:16:47 -0700 (PDT)
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 24 Mar 2017 16:16:47 -0400
X-Google-Sender-Auth: 6Ak-AWWuzn3pJmimYV2UYMrZfhI
Message-ID: <CADZyTkk512LR=cxOsmK_nOO3RdSi9ZVm_aXyqqMMCmSUfKO63w@mail.gmail.com>
To: "lwip@ietf.org" <lwip@ietf.org>, IPsecME WG <ipsec@ietf.org>
Content-Type: multipart/alternative; boundary="001a11449ffc555c01054b7facb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/j3IuFdGNW03IGehVyv_cFNDiXs0>
Subject: [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: Fri, 24 Mar 2017 20:16:52 -0000

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.
Does it sounds reasonable that security gateways implements the longest
match lookup or at least lookup considering IP addresses ?

Yours,
Daniel

On Mon, Mar 13, 2017 at 9:58 AM, Daniel Migault <daniel.migault@ericsson.com
> wrote:

> Hi,
>
> Please find an update of a guidance for light implementation of standard
> ESP. Feel free to comment!
>
> Yours,
> Daniel
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, March 13, 2017 9:57 AM
> To: Tobias Guggemos <guggemos@mnm-team.org>; Daniel Migault <
> daniel.migault@ericsson.com>
> Subject: New Version Notification for draft-mglt-lwig-minimal-esp-04.txt
>
>
> A new version of I-D, draft-mglt-lwig-minimal-esp-04.txt
> has been successfully submitted by Daniel Migault and posted to the IETF
> repository.
>
> Name:           draft-mglt-lwig-minimal-esp
> Revision:       04
> Title:          Minimal ESP
> Document date:  2017-03-13
> Group:          Individual Submission
> Pages:          10
> URL:            https://www.ietf.org/internet-drafts/draft-mglt-lwig-
> minimal-esp-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-
> esp/
> Htmlized:       https://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-mglt-lwig-minimal-
> esp-04
>
> Abstract:
>    This document describes a minimal version of the IP Encapsulation
>    Security Payload (ESP) described in RFC 4303 which is part of the
>    IPsec suite.
>
>    ESP is used to provide confidentiality, data origin authentication,
>    connectionless integrity, an anti-replay service (a form of partial
>    sequence integrity), and limited traffic flow confidentiality.
>
>    This document does not update or modify RFC 4303, but provides a
>    compact description of how to implement the minimal version of the
>    protocol.  If this document and RFC 4303 conflicts then RFC 4303 is
>    the authoritative description.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>