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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
