Valery Smyslov writes: > > > In normal IKEv2 each side selects its own IKE SPI, but in > > > G-IKEv2 it is impossible. It is the GCKS that provides GMs with SPI > > > for rekey SA and GMs will have to use it to select the right SA. > > > > Yes, but as the GM will always only use the first 8 octets of the > > IKE SPIs in the IKEv2 header we could simply use that to identify > > the IKE SA. > > I think the GM will use the whole 16 bytes from the header for > multicast rekey SA (those, with the multicast destination IP). > Otherwise we will have 8 unused octets for SPIr in the IKEv2 header.
But as the "GCKS MUST make sure that the sole first 8 octets (corresponding to "Initiator's SPI" field in the IKEv2 header) uniquely identify the Rekey SA." there is no point of GM to check Responder SPI at all. We could simply say that it is either random or all ones or something else (yes we do want to include it in the header to keep header same as IKEv2). So I think my main point is either use the 16-octet SPI pair to identify the G-IKEv2 SA or use 8-octet Initiator SPI and ignore the content of the Responder SPI part in IKE header, and dont send it in notifies. The current method seems to be mix of those two. The notify sends full 16-octets, but in IKE header only first 8-octets really matter, as they need to be unique. If we want to use 16-octet SPI then we should remove that text about first 8-octets uniquely identify the Rekey SA, just use full 16-octets all the time. If we say first 8-octets uniquely identify the Rekey SA, then we could leave out last 8-octets in notifies, and say they are sent all ones in IKE header (i.e. 0xffffffff ffffffff)... > > > Obviously, GCKS is unaware of the SAs each GM might have (it may be a > > > member of several groups controlled by different GCKSs and besides it > > > may have a lot of ordinary IKE SAs too), so the GCKS selects SPI in > > > random. To minimize the chance of collision it is better to use full > > > 16 bytes of available room in IKEv2 header instead of only selecting > > > SPIi, since GMs won't contribute to this process anyway. > > > > Probability of having random collision with IKE SA when only using > > 64-bit IKE SPI is that I would ignore that. This is long lived SPI > > value, typically it will stay same for long time (hours, days, or > > even weeks). > > > > Also I think there is also the source IP address of the IKE > > packets that can be used to identify the GCKS so there should not > > be problems even if the SPIi somehow should collide. > > I wouldn't rely on source IP. It may change over time (NAT, DHCP > etc.). This would only be needed if you happen to have collision for 8-octet SPI with current draft already. I mean if two GCKS happen to pick same 8-octet Initiator SPI then you are going to use IP address to separate them as the text says they MUST be unique... Either way, I do not have strong opinion about this, it just feels bit wrong. -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
