Jitender Arora writes: > Load balancer by definition needs to know the devices where it is > sharing the load to, so I do not consider that a problem. Also if the > redirection is done in the IKE_SA_INIT phase then the application > support required is very minimal. > > > Jitender--> Adding the IKEv2 stack on the Load balancer defeats the > purpose of having a generic load balancer, which can work for any > type of sessions. For example in our case we will be load balancing > the SIP traffic, IPSEC tunnels and will add more types of > applications. So this box is not going to handle only the load > balancing of the IPSEC tunnels. Most of the vendors would like the > load balancer to be generic and not application dependent.
So you have generic load balancer, which doesn't want to know anything about the protocols, but then you are adding more and more types of application to be handled by the same load balancer. This is bit of a contradiction. Your generic load balancer support can easily be so that it forwards all IKEv2 and IPsec traffic destinationed directly to the security gateways to those gateways (or the router will already take care of that if you do not want to route packets through load balancer), and when new IKEv2 connection comes in with the published IP-address you either process that in the load balancer, or forward it to any of the security gateways (or one master security gateway) which will then do IKEv2 redirect to proper gateway. I still do not see any need for why the IKEv2 in the load balancer should support your extended IKEv2 protocol, when it can implement the normal redirect protocol and redirect the whole IPsec and IKEv2 SA combo to suitable gateway. In your proposal who is terminating the IKEv2 connections? Who is sending the N(TUNNEL_ADDRESS) payloads? Who is processing the IPsec traffic? > Jitender--> You are assuming that the Load Balancer will just be > handling the IKE_SA_INITS, but in reality it will be communicating > with all the security gateways also to get real time information > about the number of sessions on each security gateway, CPU usage and > all other matrix which will help in deciding where the new tunnel > will be redirected. Yes, but that protocol is outside the scope of this discussion, or at least that is what I assumed, as your draft does not cover any of that. The load balancer does NOT need to process any IPsec or IKEv2 packets after the initial IKE_SA_INIT to do that. It just needs to get some statistics and other information from gateways so it can make sure it forwards next incoming connection to suitable free sgw. It can also provide information to the SGWs when they should move some IPsec/IKEv2 SAs to some other SGW when one of them is getting too loaded. The SGW can do that using MOBIKE, provided they first use some other protocol and sync the IPsec and IKEv2 state between the old and new SGWs. > So there will be much more activity going on the > laod balance than just handling 277 connection attempts per sec. I > would think that we don't need to go into the design discussions as > to whether this is feasible or not. What we are proposing is the > cleaner way of handling the load balancing issues. I do not think it is cleaner way, as I think it makes things very messy if the IKEv2 and IPsec SAs are terminated in different locations. The IKEv2 do have all kind of implicit assumptions about the IKEv2 and IPsec address connection, and implementations have even more. We noticed this when we were making MOBIKE, and there things were easy as we knew that all the IP-addresses are still talking to the same node. In your case this would not be true, and that makes things even more complicated. > Jitender---> I did not get this, as I said all the IKEv2 signaling > will pass through the Load balancer. What we don't want is the IPSEC > traffic from 2 million clients to pass through the Load balancer. Why do the IKEv2 signaling need to pass through the load balancer? Why it cannot go directly to the suitable SGW after the initial IKE_SA_INIT redirect? -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
