] defines the SPI as a mandatory 32-bit field.
The SPI has local significance to index the Security Association (SA). As described in Section 4.1
of RFC 4301
, nodes supporting only unicast communications can index their SA using only the SPI. Nodes supporting multicast communications also require the use of IP addresses; thus, SA lookup needs to be performed using the longest match.
For nodes supporting only unicast communications, indexing the SA using only the SPI is RECOMMENDED
. The index may be based on the full 32 bits of the SPI or a subset of these bits. The node may require a combination of the SPI as well as other parameters (like the IP address) to index the SA.
Values 0-255 MUST NOT
be used. As per Section 2.1
of RFC 4303
, values 1-255 are reserved, and 0 is only allowed to be used internally and MUST NOT
be sent over the wire.
] does not require the 32-bit SPI to be randomly generated, although that is the RECOMMENDED
way to generate SPIs as it provides some privacy and security benefits and avoids correlation between ESP communications. To obtain a usable random 32-bit SPI, the node generates a random 32-bit value and checks it does not fall within the 0-255 range. If the SPI has an acceptable value, it is used to index the inbound session. Otherwise, the generated value is discarded, and the process repeats until a valid value is found.
Some constrained devices are less concerned with the privacy properties associated with randomly generated SPIs. Examples of such devices might include sensors looking to reduce their code complexity. The use of a predictive function to generate the SPI might be preferred over the generation and handling of random values. An implementation of such predictable function could use the combination of a fixed value and the memory address of the Security Association Database (SAD) structure. For every incoming packet, the node will be able to point to the SAD structure directly from the SPI value. This avoids having a separate and additional binding and lookup function for the SPI to its SAD entry for every incoming packet.
SPIs that are not randomly generated over 32 bits may have privacy and security concerns. As a result, the use of alternative designs requires careful security and privacy reviews. This section provides some considerations for the adoption of alternative designs.
The SPI value is only looked up for inbound traffic. The SPI negotiated with IKEv2 [RFC 7296
] or minimal IKEv2 [RFC 7815
] by a peer is the value used by the remote peer when it sends traffic. The main advantage of using a rekeying mechanism is to enable a rekey, which is performed by replacing an old SA with a new SA, both indexed with distinct SPIs. The SPI is only used for inbound traffic by the peer, which allows each peer to manage the set of SPIs used for its inbound traffic. The necessary number of SPIs reflects the number of inbound SAs as well as the ability to rekey those SAs. Typically, rekeying an SA is performed by creating a new SA (with a dedicated SPI) before the old SA is deleted. This results in an additional SA and the need to support an additional SPI. Similarly, the privacy concerns associated with the generation of non-random SPIs is also limited to the incoming traffic.
Alternatively, some constrained devices will not implement IKEv2 or minimal IKEv2 and, as such, will not be able to manage a rollover between two distinct SAs. In addition, some of these constrained devices are likely to have a limited number of SAs; for example, they are likely to be indexed over 3 bytes only. One possible way to enable a rekeying mechanism with these devices is to use the SPI where, for example, the first 3 bytes designates the SA while the remaining byte indicates a rekey index. SPI numbers can be used to implement tracking the inbound SAs when rekeying is taking place. When rekeying an SPI, the new SPI could use the SPI bytes to indicate the rekeying index.
The use of a small, limited set of SPI numbers across communications comes with privacy and security concerns. Some specific values or subsets of SPI values could reveal the model or manufacturer of the node implementing ESP or reveal a state such as "not yet rekeyed" or "rekeyed 10 times". If a constrained host uses a very limited number of applications, eventually a single one, the SPI itself could indicate what kind of traffic is transmitted (e.g., the kind of application typically running). This could also be correlated with encrypted data size to further leak information to an observer on the network. In addition, use of specific hardcoded SPI numbers could reveal a manufacturer or device version. If updated devices use different SPI numbers, an attacker could locate vulnerable devices by their use of specific SPI numbers.
A privacy analysis should consider at least the type of information as well as the traffic pattern before deciding whether non-random SPIs are safe to use. Typically, temperature and wind sensors that are used outdoors do not leak privacy-sensitive information, and most of their traffic is expected to be outbound traffic. When used indoors, a sensor that reports an encrypted status of a door (closed or opened) every minute might not leak sensitive information outside the local network. In these examples, the privacy aspect of the information itself might be limited. Being able to determine the version of the sensor to potentially take control of it may also have some limited security consequences. Of course, this depends on the context in which these sensors are being used. If the risks associated to privacy and security are acceptable, a non-randomized SPI can be used.