Subject: [IPsec] Number of fixed SPI

From: Daniel Migault <[email-masked]>
Date: Fri, 24 Mar 2017 16:16:47 -0400

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 <[email-masked]
> wrote:

> Hi,
>
> Please find an update of a guidance for light implementation of standard
> ESP. Feel free to comment!
>
> Yours,
> Daniel
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 13, 2017 9:57 AM
> To: Tobias Guggemos <[email-masked]>; Daniel Migault <
> [email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 24 Mar 2017 20:41:28 +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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 24, 2017 4:25 PM
To: Daniel Migault <[email-masked]>
Subject: Re: [IPsec] Number of fixed SPI

> On Mar 24, 2017, at 4:16 PM, Daniel Migault <[email-masked]> 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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Mar 2017 18:30:04 -0400 (EDT)

On Fri, 24 Mar 2017, Daniel Migault wrote:

> 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.

This is pretty dangerous. Half a year ago or so we saw the Transcript
Collsion Attacks that could have succeeded if we hadn't used random
SPI numbers to prevent pre-calculation in the attack. Using a set of 10
non-random SPI numbers would potentially make this device vulnerable to
this attack.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Mar 2017 13:40:12 -0400 (EDT)

On Fri, 24 Mar 2017, Paul Wouters wrote:

>> SPI, but instead

As Tero pointed out to me just now, those were IKE SPI's and not ESP
SPI's to I guess there is no security issue here :)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 26 Mar 2017 21:45:32 +0300

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.
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 28 Mar 2017 22:49:45 -0500

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 <[email-masked]> wrote:

> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>