HI Tero, > Valery Smyslov writes: > > > I did understand that, but I do not see point of sending extra > > > 8-octets as > > the first 8- > > > octets already identifies the IKE SA... > > > > The point is that we want to re-use IKEv2 header, which contains two > > IKE SPIs. > > Sure, but this does not have anything to do with the issue in hand, i.e., how to > identify the IKE SA in the notify payload. The notify payload normally only has 8 > octets to identify the IKE SA and now you suddenly want to have 16 octets instead.
8 octets are used for IKE protocol SA, 16 octets would be used for GIKE_REKEY protocol SA. I see no misuse of the Notify payload here - SPI size is variable by definition and is determined by the protocol the SA relates to. > > 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. > > 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.). > If I remember correctly the IKE SA packets the GCKS is sending will be using the > unicast source IP address of the GCKS, and may contain either unicast address of > the GM or the multicast address. The source address would not be multicast or > broadcast address. Correct. Regards, Valery. > kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
