Hi Tero,
My comments are inline.
Thanks,
Jitender
-----Original Message-----
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Monday, May 03, 2010 8:40 AM
To: Jitender Arora
Cc: Yaron Sheffer; ipsec@ietf.org
Subject: RE: [IPsec] New draft posted
Jitender Arora writes:
> Currently the IKEv2 does not allow the IKEv2 signaling and the
> IPSEC traffic to go to different IP addresses, so this is the
> problem this draft is trying to solve.
>
> The application where it is required now is the load balancing
> of the IPSEC tunnels. Suppose in a network there are 10
> Security-Gateways and each of these security gateways can handle
> 200000 IPSEC tunnels using the IKEv2 signaling. Now for this
> network if we need a load balancer device which can balance the
> tunnels across these security gateways, this load balancer
> device will be handling the IKEv2 signaling coming from the 10
> *200000 clients which is 2 Million clients. In addition to
> handling the IKEv2 signaling from these clients, this will also
> have to handle the bidirectional IPSEC traffic between the
> clients and security gateways. So in this case this load
> balancing device needs to be very scalable and also high
> performance box. This might not be practical.
The easiest way is to use already standardized IKEV2 redirect and
redirect the incoming flows from the single ip to one of those load
balancing gateways in such way that IKEv2 SA and IPsec SA are on the
same IP-address.
If the SA needs to be moved because traffic distribution changes, and
SA flows needs to be moved from one machine (IP-address) to another,
you can use already standardized MOBIKE to change the termination
point where the IKEv2 and IPsec SA flows are terminated (i.e. the
outer IP-address)
Jitender--> Currently we are using this approach (basically using the redirect
and the Mobike).
This is causing the following issues:
1. If the redirect message is handled by the Load Balancer, the load balancer
needs to be IKEv2 aware and also it needs to know the IP addresses of the
Security Gateways for which it is responsible. This can cause the performance
issues as the Load Balancer should not be application aware and should do the
load balancing based on the layer 3/layer 4 information.
2. If the Load Balancer passes this IKEv2 messages directly to the security
gateways using the layer 3 information, the security gateway will then have to
send the redirect to the client back through the LoadBalancer and telling the
client to talk to different address now. This again causes an extra message
exchange to achieve the load balancing.
If you want to use same outer IP-address for all of the traffic even
that is easy to do provided the cluster members follow certain rules.
For example the SPIs (both ESP and IKEv2 SPIs) can use some bits to
indicate which of the gateways is supposed to handle them. This way
all the outer IP-addresses can be same but the load balancer in front
of the actual gaweways can very quickly use simple hardware to forward
packets to correct gateway.
Jitender--> This can simply be done based on the layer3/layer4 information,
which is what we are planning to do.
I do not really understand why the load balancer should be taking care
of the IKEv2 traffic? Isn't it easier that each security gateway takes
care of the IKEv2 traffic of the IPsec SAs associated with them.
Jitender--> I think, I did not make this clear, the Load Balancer will not take
care of the IKEv2 traffic, it will just pass through the IKEv2 traffic to the
security gateways without handling them. But all the IKEv2 traffic will have to
go through this load balancer so that the IKEv2 signaling can take place
between the same addresses.
In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together,
and running them on separate machines is very complicated (We just had
long discussion about this on the list, i.e. what kind of failure
models can happen and what cannot happen).
Jitender--> If this has been captured somewhere, can you please point us to
that link.
> So to solve this problem, this draft proposes that if we can
> allow the IPSEC traffic on the different addresses than the
> IKEv2 signaling, the load balancer can handle only the IKEv2
> signaling and chose the right security gateway, and this
> security gateway can tell the client to send the IPSEC traffic
> directly to the security gateway without going through the Load
> Balancer.
I think mkaing single machine taking care of 2 million IKEv2
connections is going to be challenging, and it is much easier to make
ten machines taking care of 200,000 clients in addition to taking care
of the IPsec SAs associated with those clients. This way the load
balancer has very easy job to just redirect the IKEv2 clients to
suitable security gateway and then that gateway can take care of all
the traffic.
> This way the load balancer does not need to worry
> about the IPSEC traffic and this will not put a lot of strain on
> these boxes.
It is possible to create system where the load balancer can very
cheaply forward packets to real gateway based on for example the IPsec
SPI (this does require coordination with the machines creating those
IPsec SAs and allocating those SPIs). Same can be used for IKE SPIs
too.
> You are right, the IKEv2 SA and the CHILD SA will still be on
> the same machine, but will be using the different addresses.
So it is much better to use IKEv2 redirect and MOBIKE to change both
IKEv2 SA and IPsec SA outer addresses either during the initial setup
or after that.
Jitender--> Please let me know if this makes sense.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
