Do IKEv2 ESP proposals really require a unquie SPI per proposal?

Question

When one peer is trying to negotiate an ESP SA, it sends a security association (SA) payload to the other peer. This SA payload must contain at least one proposal, suggesting at least one encryption and one integrity transform to use. It may also contain multiple proposals in preferred order, in which case the other peer can pick either proposal. If a peer wants to suggest both, standard crypto ciphers and combined-mode ciphers without an extra integrity, it even has to use two separate proposals, according to RFC 7296, Section 3.3. And they also show an example of how an SA with two such proposals could look like:

SA Payload
      |
      +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
      |     |            7 transforms,      SPI = 0x052357bb )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 128 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 192 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 256 )
      |     |
      |     +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
      |     +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
      |     +-- Transform ESN ( Name = ESNs )
      |     +-- Transform ESN ( Name = No ESNs )
      |
      +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
            |            4 transforms,      SPI = 0x35a1d6f2 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 128 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 256 )
            |
            +-- Transform ESN ( Name = ESNs )
            +-- Transform ESN ( Name = No ESNs )

If you look closely, you'll notice that these two proposals have two different SPI values. But keep in mind, that the other peer may only either select proposal #1 or #2 or reject both of them, so one of these proposals is rejected for sure, maybe even both.

Nowhere does the RFC state that individual proposals must have a unique SPI. Sure, every SA must have a unique SPI as the SPI is what identifies the SA. And a proposal for a new SA must not use the same SPI as has already been used for a previous SA, that's for sure. But here both proposals are for negotiating a single SA, not two different ones. In the end, if one proposal is accepted, that proposal will apply to the SA and the other one will be ignored.

I find nothing in the RFC that would require this to be the case. If both would have the same SPI, would that be a standard violation? If so, what line of which standard would that violate? Again, different SAs require different SPIs, no question, but these are all proposals for a single SA.

Answer 1

If both would have the same SPI, would that be a standard violation?

No, that's perfectly fine. The SPI is a completely local decision. It could be a random value and shared between all proposals. Or it could be tied to the proposed protocols, or even encode some locally relevant information, which then might require different SPIs for different proposals.

See the definition in RFC 4301:

Security Parameters Index (SPI)
   An arbitrary 32-bit value that is used by a receiver to identify
   the SA to which an incoming packet should be bound.  For a unicast
   SA, the SPI can be used by itself to specify an SA, or it may be
   used in conjunction with the IPsec protocol type.  Additional IP
   address information is used to identify multicast SAs.  The SPI is
   carried in AH and ESP protocols to enable the receiving system to
   select the SA under which a received packet will be processed.  An
   SPI has only local significance, as defined by the creator of the
   SA (usually the receiver of the packet carrying the SPI); thus an
   SPI is generally viewed as an opaque bit string.  However, the
   creator of an SA may choose to interpret the bits in an SPI to
   facilitate local processing.