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 [kivi...@iki.fi]
Sent: Tuesday, April 27, 2010 7:19 AM
To: Jitender Arora
Cc: Yaron Sheffer; ipsec@ietf.org
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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to