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