[IPsec] Multiple IPsec proposals, same SPI?

[Tero Kivinen <[e-mail]>]

Dan McDonald writes:
> Consider the example in section 3.3 of IKEv2bis, which I've edited for
> brevity:
> 
>    SA Payload
>       |
>       +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
>       |     |            7 transforms,      SPI = 0x052357bb )
> 
> 	(either way for ESN, three CBC ciphers, two hashes)
> 
>       +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
>             |            4 transforms,      SPI = 0x35a1d6f2 )
> 	(either way for ESN, two GCM ciphers)
> 
> the example shows two distinct SPI values.
> 
> Is it *required* that the SPI values be different?

It is not required that SPI values are different.

But it is required that recipient accepts such proposal where they are
different. The SA allocation is completely local matter.

> For example, PF_KEY has SADB_GETSPI which merely reserves an inbound
> SPI value, without ANY other properties attached. IN theory, given
> the above example, I could instead issue:
> 
>    SA Payload
>       |
>       +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
>       |     |            7 transforms,      SPI = 0x052357bb )
> 
> 	(either way for ESN, three CBC ciphers, two hashes)
> 
>       +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
>             |            4 transforms,      SPI = 0x052357bb )
> 	(either way for ESN, two GCM ciphers)
> 
> since I merely did a GETSPI which reserved 0x052357bb.

Yes, that is also completely legal proposal.

I.e. both versions must be supported by the receiving end, but sender
end can only use whatever is more convinient for him. In some
environments the SPI selection can be done so that part of the SPI
indicates for example the crypto processor which will be taking care
of the traffic, and if there are multiple crypto processors which have
different capabilities, it might not be possible for sender end to
select same SPI for all proposals. In other environments like in
yours, it might be that SPI is same because it is allocated using one
PF_KEY operation.

Unfortunately this is also true for IKE SA rekey (where the half of
the IKE SA SPIs are inside the Proposal payloads inside SA Payload),
and that would be one place where I would like to change specification
so they would need to be same in all proposals, but it is too late for
that change.
-- 
[e-mail]