Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa

From: Daniel Migault <[email-masked]>
Date: Mon, 17 Aug 2015 13:47:00 -0400

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-masked]> 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-masked]
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>