Frank Bailey writes: > In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that > the peers should establish an 'equivalent' SA. The question I have, > is what is meant by equivalent?
It means mostly same... I.e. protecting same traffic and using same parameters, ciphers etc. > Does that mean there can only be one proposal in the SA when > rekeying? As the RFC5996 says that traffic selectors and algorithms SHOULD NOT be different, there is no point of including more than one proposal. The best is just to propose exactly same algorithms, and traffic selectors which are used by the Child SA you are rekeying. > And, does that proposal have to match the currently used algorithms > for that SA (i.e. the new SA, must match the SA (as far as > transforms) to be rekeyed)? The RFC5996 has "SHOULD" for that, so unless you have good reasons (which you can explain) why you are not following that SHOULD then that is the way to go. > In section 2.18, 4th paragraph, it mentions that the 'old and new IKE SA > may have selected a different PRF. ...' Which leads me to think that > we can re-negotiate the transforms during a rekey. This is for IKE SA rekey. The crypt algorithms and traffic selectors "SHOULD" in the RFC5996 only applies to the Child SAs. For the IKE SA there is no suggestion that you need to keep ciphers same. The reason for why the algorithms SHOULD NOT change during the Child SA rekey is that on some implementation or on some hardware the rekey is optimized so that the newly created Child SA does not really allocate new full SA, but instead the newly rekeyed SA is added to the existing SA with some new parameters (i.e SPI and keying material). Then when the old SA is deleted the rekeyed SA is moved to be the primary SA of this kind of bundle. This is done so that the statistics and so on can be kept over the SA rekeys etc. This is purely local implementation issue and this kind of optimization quite often share lots of data with the previous SA, and those shared data can and often will include algoritms and the traffic selectors. So following that SHOULD NOT allows more efficient use of resources on some implementations. Of course most likely those implementation will enforce this by always picking the same set of algorithms the are already using on the old SA if they have been proposed multiple algorithms. On the other hand if the proposed set does not include currently used crypto algorithms, those implementations might return error like NO_PROPOSAL_CHOSEN for the rekey attempts, even when similar alrogithm set could be used to create SA from the scratch. This might cause the situation where the host A tries to rekey and host B always says NO_PROPOSAL_CHOSEN and finally the Child SA expires, and then it is created again from the beginning (i.e. no rekey) and then it succeeds, meaning that this setup still works, but is not as optimized as it could be and it might cause few packets to be lost during the operation. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
