Re: [IPsec] New draft posted

[Jitender Arora <[e-mail]>]

Comments inline.



-----Original Message-----
From: Tero Kivinen [mailto:[e-mail]]
Sent: Wednesday, May 12, 2010 7:41 AM
To: Jitender Arora
Cc: [e-mail]
Subject: Re: [IPsec] New draft posted



Jitender Arora writes:

> 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.



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.



I would think that the by separating the IPSEC traffic and ikev2 signaling can make the architectures much cleaner and will be useful in other applications as well.



Also there is no need that the load balancer itself needs to be acting

as application gateway, the published IP address for the IKEv2

connections can also be some other IP-address, i.e. that host does not

need to be on the path of the real traffic. If this one host is only

parsing IKE_SA_INIT packets and sending redirect backs any old 386 box

you can find from your junk pile will be able to handle the traffic up

to millions of clients (million clients, each connecting for example

once per hour means there is 277 connection attempts per second, and

any old box can receive 277 udp packets and send 277 udp replies back

(in completely stateless manner)).



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. 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.



> 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.



Those extra messages only happen during the setup phase, and I would

expect the load balancer can pass through those less than 300 messages

per second. If it cannot, then you have much bigger problems when the

real traffic starts to come in...



> 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.



So if the load balancer cannot handle few hundred packets per second

to passthrough then I think you should really consider replacing the

hardware.



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.



For normal IPsec use the IKEv2 packet are not send periodically at

all. There is 2+2 packets in the beginning. There might be one DPD

exchange over IKEv2 SA when the ESP traffic stops, but after that

there shouldn't be anything until the ESP traffic restarts.



So there should very little IKEv2 traffic, and in normal case it is

limited to about 6 packets in total over the whole lifetime of the

IKEv2 SA.



> 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.



Jitender--> what I propose is that I will update the document to include the usage scenario in more details and we can discuss again.



http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html

--

[e-mail]