> -----Original Message----- > From: Paul Wouters [mailto:[email protected]] > Sent: Saturday, October 28, 2017 10:28 PM > To: Hu, Jun (Nokia - US/Mountain View) <[email protected]> > Cc: Valery Smyslov <[email protected]>; 'Tero Kivinen' <[email protected]>; > [email protected] > Subject: Re: [IPsec] Agenda for IETF 100 > > On Sat, 28 Oct 2017, Hu, Jun (Nokia - US/Mountain View) wrote: > > >> [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange > >> Protocol Version 2 (IKEv2)) can't be used for this purpose? > >> > >> The problem with IKE Redirect is that it requires IKE SA to be > >> re-established from scratch. > >> It consumes quite a lot of resources and takes noticeable amount of time. > >> Moreover, in some cases it could require human interaction (in case > >> of some EAP methods or if access to client's credentials requires > >> entering PIN), so it may be inappropriate. > >> The idea is to have a solution that utilizes already established IKE > >> SA and moves it (along with its Child SAs) from one cluster member to > >> another without creating new IKE SA. > > > > [HJ] two questions: > > 1. this sound interesting, however how to do it securely is the most > important question, do you already have draft? > > > > 2. if the use case is load-balance, then wouldn't it be better off to make > > a > selection right upon client connects (e.g. redirect during IKE_AUTH) than move > SA around after tunnel is established ? > > I think a document describing how best to load load balancing AND failover > support for IPsec would be useful, irrespective of the existing RFC's or > existing/future drafts which we would use. For example, a document listing: > > - Client behaviour to Access VPN failover > - Net-to-Net failover over different uplinks > - Hardware pair failover with state within a datacenter > - Crypto Mesh migration > - Maybe some IPsec/NHRP advise?
[HJ] I think it would be good to have use case/requirement defined first, because different use cases has different requirements, which might leads to different solution; e.g. remote-access client (e.g. road warrior) connect to one cluster of GWs (ad hoc) is different from a branch router connects to HQ (always on); where latter could just use routing/ecmp to achieve load balancing, doesn't need anything new; > Another thing we might want to reconsider is something to talk about mesh > encryption / auto-vpn in general. While earlier work to come up with a single > solution failed, there is still a market need, and I'm a little fearful of SDN > removing IKE from the setup. [HJ] there is clear market requirement for an auto-discover encryption VPN, however again depends on the use case, the solution might not need to extend IPsec; for example, for router interconnection , I could see extending BGP (e.g. tunnel encaps attr) to carry gw address or other ipsec profiles info along with routes be a solution > Paul > Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
