Subject: Re: [IPsec] New draft posted

From: Jitender Arora <[email-masked]>
Date: Sun, 2 May 2010 23:29:30 -0400

Hi Tero,

    Thanks for your feedback.

    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.

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

    You are right, the IKEv2 SA and the CHILD SA will still be on the same machine, but will be using the different addresses.

    Hope this helps, Please let me know what you think.

Thanks,
Jitender
________________________________________
From: Tero Kivinen [[email-masked]]
Sent: Tuesday, April 27, 2010 7:19 AM
To: Jitender Arora
Cc: Yaron Sheffer; [email-masked]
Subject: Re: [IPsec] New draft posted

Jitender Arora writes:
> 1.  I will point the section 5.1 in the introduction itself that way
> the purpose and applications of the draft are clear.

After I read the section 5.1 (I skipped most of the other draft as I
needed to know first WHY this is needed before I care about HOW it is
implemented), and I do not really see enough text there to cause me to
read the HOW part.

So I would need better and more text about WHY this extension is
needed. Why it is important that the IKEv2 SA and Child SA uses
different outer addresses? Who is supposed to terminate the IKEv2 SA
and who is supposed to terminate the Child SAs. Is this assuming that
IKEv2 SA and Child SA are still on the same machine or what? If so,
why not just use the IP address of that host for both IKEv2 SA and
Child SA?

So I think the usage scenarios (WHY part) is much more important than
the actual protocol (HOW part), and it should be clear from the
beginning.

Currently this draft mostly assumes there is problem, but it does not
explain why you think the problem actually exists or what the problem
is.
--
[email-masked]

---

From: <[email-masked]>
Date: Mon, 3 May 2010 09:18:07 +0200

Jitender Arora wrote:

>     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.
> 
>     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. 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.
> 
>     You are right, the IKEv2 SA and the CHILD SA will still be on the
> same machine, but will be using the different addresses.

If the IKEv2 SA and Child SAs are on the same box, why isn't RFC 5685
sufficient to solve this problem?

RFC 5685 doesn't support using different IP addresses for IKEv2 and
ESP/AH, but it would allow bypassing the load balancer for established
IKE SAs, precisely they way you describe. 

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 3 May 2010 15:39:33 +0300

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)

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.

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.

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

>     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. 
-- 
[email-masked]

---

From: Jitender Arora <[email-masked]>
Date: Tue, 4 May 2010 22:04:39 -0400

Hi Tero,

    My comments are inline.

Thanks,

Jitender

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]]
Sent: Monday, May 03, 2010 8:40 AM
To: Jitender Arora
Cc: Yaron Sheffer; [email-masked]
Subject: RE: [IPsec] New draft posted

same IP-address.

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.

Jitender--> This can simply be done based on the layer3/layer4 information, which is what we are planning to do.

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.

Jitender--> If this has been captured somewhere, can you please point us to that link.

the traffic.

too.

or after that.

Jitender--> Please let me know if this makes sense.

--

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 12 May 2010 14:41:23 +0300

Jitender Arora writes:
> 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.

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

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

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.

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

http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html
-- 
[email-masked]

---

From: Jitender Arora <[email-masked]>
Date: Tue, 18 May 2010 22:37:57 -0400

Comments inline.

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

Jitender Arora writes:

> Jitender--> Currently we are using this approach (basically using

> the redirect and the Mobike).

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.

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.

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.

IKEv2 SA.

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

--

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 May 2010 16:04:50 +0300

Jitender Arora writes:
> 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?
-- 
[email-masked]