> > 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)...
I see your point. I removed the requirement that the first 8 octets uniquely identify SA. I think that it is more appropriate from architecture point of view to have both SPIi and SPIr in the header meaningful, rather than use only one of them and fill in the other with predefined or random value. What about the text - I recall that it was added by me to simplify co-existence of IKE and GIKE_REKEY SAs in the same SADB on GCKS. However, I now realize that this is an implementation optimization and not the protocol requirement. In other words, the GCKS can always select rekey SPI so, that its first half is unique (among all SPIs, both for IKE and rekey SAs), but the GMs will have to use whole 16 bytes to found the rekey SA. I published a new -14 version. Regards, Valery. > > > > 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
