Hi, Thank you Tero for providing these explanation, We would like to update the current draft with additional text on SA duplication and its associated issues raised by Paul. We believe it would also help to position/understand Clone IKE SA. The text is expected to be added in the introduction. Feel free to let us know whether you beleive the text is clear enough, or if you have any additional comments before we publish a new version.
Introduction [...] Another scenario is a load-balancing solution. Load-sharing clusters often are built so, that they are transparent for VPN End Users. In case of IPsec it means that IKE and IPsec SA states are duplicated on every cluster node where load balancer can redirect packets. The drawback of such approach is that anti-replay related data (in particular Sequence Number) must be transactionally syncronized betweed participating nodes per every outgoing AH or ESP packet, which makes building high-speed systems problematic. Another approach for building load-balancing systems is to make VPN End Users aware of them, which allows to have two or more Security Gateways sharing the same ID, but each having its own IP address. In this case the VPN End User first establishes an IKE SA with one of these gateways. Then, at some point of time the gateway takes a decision to move client to a different cluster node. This can be done with Redirect Mechanism for IKEv2 [RFC5685]. The drawback of such approach is that it requires new IKE SA to be established from scratch, including full authentication. In some cases this could be avoided by using IKEv2 Session Resumption [RFC5723] with a new gateway. However this requires VPN End User to know beforehand which new gateway to connect to. So it is desirable to be able to clone existing IKE SA, to move it to a different Security Gateway, and then to indicate VPN End User to use this new SA. This would allow participating Security Gateways to share the load between them. BR, Daniel and Valery On Fri, Nov 28, 2014 at 8:50 AM, Tero Kivinen <[email protected]> wrote: > 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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
