Prashant Batra (prbatra) writes:
> What my intention was to combine this idea with draft - "Alternate
> Tunnel Addresses for IKEv2" that is already there,
> which says something like this (for tunnel mode IPSec)-
>
> IKE_AUTH -
> IKE_IP_I:500 -> IKE_IP_R:500)
> HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
> [IDr,]AUTH, SAi2, TSi, TSr, [N(TUNNEL_ADDRESS)]} -->
>
> (IKE_IP_R:500 -> IKE_IP_I:500)
> <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
> SAr2, TSi, TSr, [N(TUNNEL_ADDRESS)]}
> Here, [TUNNEL_ADDRESS] will specify the IPSec tunnel outer IP pairs,
> which might be different from IKEv2 IP pairs.
I do not know abou the "Alternate Tunnel Addresses for IKEv2", but I
can see that it would have all kind of problems with the NAT-Travelsal
and also with MOBIKE, at least if I understood correctly what it is
(i.e. if the outer IP-address of the IKE SA and the Child SAs are
different you will have all kind of issues with NAT-T and MOBIKE).
> So, if there is a load-sharing between two gateways and the
> user/application starting the IKEv2 negotiation,
> knows that the gateway has 5 ip-addresses used for this purpose, 5
> different IPSec tunnels need to be established
> between the gateways.
Actually if both ends have multiple addresses you might need n * m
tunnels.
> This can be achieved by 4 CREATE_CHILD_SA
> exchanges following IKE_AUTH specifying the rest of 4 [TUNNEL_ADDRESS].
Usually it is easier to do load balancing by moving different clients
to different hosts, which solution does not have this problem. If load
balancing is needed between two big load-balanced servers because the
traffic between them is so much that one host cannot cope with it
(i.e. 10 Gbit/s or faster, as current high end PCs can already do
several Gbit/s with software crypto), I would not assume there is that
many servers connecting to the same load balancing cluster. Also as in
such setups the IKE SAs will be up and running mostly for ever,
meaning the initial exchange setup overhead will most likely be very
small compared to the things like Child SA rekeys and so on.
In such setups doing the initial IKE SA creation and the associated
few CREATE_CHILD_SAs once should not be a problem.
> Using my idea, we can do it in a single AUTH, maybe with same set of
> algorithms or different. If we have to use same set of algorithms
> then only a single SA payload will suffice.
That will add lots of complexity to the system. I think the complexity
added is way too much, when the benefit is just omitting few extra
packets at the initial setup time that happens very rarely.
I mean that kind of load balancing servers are most likely also using
high-availibity features, meaning the same IKE SA might be up for
years, even when the hardware of the system is updated on the fly...
> [TUNNEL_ADDRESS_LIST] might contain a range of addresses. Also,
> these addresses might belong to same ID, if ID_TYPE is FQDN, or to
> different IDs for ID_TYPE IPv4/IPv6 address. In which case ID_LIST
> can be used.
ID_LIST is for IKEv1, it is not defined for the IKEv2.
> But, any valid use-case requiring creation of multiple CHILD_SAs can
> become beneficial, by clubbing them into one exchnage
> if we consider the cost of authentication, encryption-decryption and
> network congestion on a highly loaded gateway.
Highly loaded gateway will most likely be loaded because of the Child
SA traffic, not because of the IKEv2 SA traffic. There is already
redirection mechanisms which allows moving the IKEv2 SAs from the one
node to another node in case the IKEv2 SA traffic comes an issue.
Those CREATE_CHILD_SAs exchanges are extremly fast. The actual saving
of number of packets between the gateways should not even be visible.
The major overhead in such system, will most likely come when the
IKEv2 server pushes the created Child SA information to the crypto
hardware doing the actual Child SA processing. That operation might be
much more costly than what the actual CREATE_CHILD_SAs exchange itself
is.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
