Paul Wouters writes: > On Thu, 27 Nov 2014, Valery Smyslov wrote: > > > I think that the mechanism it describes is useful and could be used > > as a building block for several solutions. For example, > > it can be used in load-sharing scenario when there are > > some gateways with different IP addresses, that share > > the same credentials. If client established IKE SA with > > any of them then the SA could be cloned and transfered > > to other nodes of this cluster without reauthentication, > > and the traffic from client then could be balanced > > among those gateways. > > That would run into replay protection problems, just like if you copy > all kernel IPsec state between machines. And I believe load sharing > when properly done should be invisible to client side and not need > special support.
Actually I tihnk the idea is to get rid of the replay protection issues. In normal case if you just copy all IKE and IPsec state between the servers, then you need to make sure you also copy all replay data. If you clone the IKE SA, move the cloned IKE SA to new IP-address (and new load sharing server in the cluster), and then create the IPsec Child SAs there, then each of the replay data is only located in the server you are talking to, and there is no need to move replay data between the cluster members. If the load sharing is done so it is invisible to the client, then you always end up problems with the replay protection data. If it is done this way where the client is aware of the different cluster members then there is no problem with the replay protection data. > I am interested in the problem, but have bad feelings about throwing > around IKE states from two peers to another peer, which this > mechanism seems to leave open. No, this draft addresses just that problem, i.e. it WILL NOT throw away IKE states from peer to another. It will simply clone the current IKEv2 SA, so after the operation there are two completely independent IKEv2 SAs. Each of those IKEv2 SAs have their own replay windows, and counters, and both have their own independent set of Child SAs. The draft mentions tha twe already have MOBIKE which can be used to move the IKEv2 SA and all associated Child SAs from one IP to another, i.e. it can be used to transfer SA from one IP address to another, and if the second IP address is not actually in the same physical box, but happens to be IP address of the another member in the shared cluster, that is something that client cannot know. The cluster just then need to make sure that it transfers the another independed IKE SA to that other peer when doing mobike operation to change the IP address. > For instance, I would much rather see some informational exchange > method or create child sa method using the existing IKE SA for > conveying this information and somehow creatie the additional new > Child SA. I do not understand what you are meaning here. > Throwing around private keys or computed shared secrets to multiple > peers worry me. Private keys do not need to be transmitted, only the SKEYSEED and material generated from there needs to be transmitted (i.e. the computed shared state). Doing load-sharing without the client knowledge, do require exactly same material to be transmitted, but in addition to that all the replay protection related material needs to be transmitted also. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
