Hi Paul, 

I think, if we are able to deduce some efficient way of doing this, it
can add value.
A highly scalable and redundant deployment might use some good amount of
load-sharing(can scale upto 4/5 sessions).
In such scenarios, doing complete IKEv2 exchanges doesn't seems
efficient or seems redundant.
If you or the group can appreciate this, I can think and come up with
some ideas.

Regards,
Prashant

-----Original Message-----
From: Paul Hoffman [mailto:[email protected]] 
Sent: Saturday, August 27, 2011 12:16 AM
To: Prashant Batra (prbatra)
Cc: [email protected]
Subject: Re: [IPsec] IKEv2 for load-sharing

On Aug 26, 2011, at 11:06 AM, Prashant Batra (prbatra) wrote:

> Hello,
>  
> RFC-4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) defines
the extension of IKEv2 to support mobile users to offer seamless
services when connected using IPSec
> and also the support for SCTP multi-homing in override mode.
>  
> To support a load-share model for SCTP(2 associations) or for that
matter for any transport protocol between 2 gateways/nodes, 2 IKEv2
tunnels are needed between the same pair of gw/nodes.
> According to the current standards, the same pair of gateways has to
go through complete IKEv2 exchange twice(atleast 2, INIT and AUTH) to
provide such a service.
> So, speaking the number of IKEv2 and IPSec tunnels needed between the
gateways will increase with the increase in the amount of load-sharing
and thus time to establish these tunnels.
>  
> Going by the fact that the identity at both the gateways would be
authenticated in the first tunnel establishment, is there a better way
to achieve load-sharing?

By "better" I assume you mean "more efficient". If so, there probably is
a "better" way to do it, but at the cost of greater complexity. I
vaguely remember this being discussed in MOBIKE, but dismissed as too
complicated for the value. Others here might remember more.

--Paul Hoffman

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to