Subject: [IPsec] Multiple Child-SA in a single exchnage

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Tue, 30 Aug 2011 11:47:39 +0530

Hello,

The Ikev2 protocol seems to be very flexible in sending payloads in the
messages.

We can specify multiple proposals of same protocol or of different
protocol (AH/ESP) in SA payload.  We can also specify multiple traffic
selectors in the TS payload.

But all this will result in one IPsec SA to be established.

If the user knows that it has to establish  2/3 CHILD_SA, will it not be
good to have a provision to specify the information for all in a single
message (IKE_AUTH).

This might save a lot of CHILD_SA exchanges.

This will be similar to including multiple DELETE payloads or including
multiple SPI's in a single DELETE payload in INFO exchange to delete
CHILD_SA's

Kindly share your valuable views on the same.

Regards,

Prashant Batra

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Aug 2011 12:57:01 +0300

> This might save a lot of CHILD_SA exchanges.

CREATE_CHILD_SA exchange is quite light weight exchange, especially if
no Diffie-Hellman is needed. If your SAs are between same endpoints
and has similar lifetimes there is no need to do Diffie-Hellman
exchanges in the CREATE_CHILD_SA, meaning the cost of doing
CREATE_CHILD_SA is just sending and receiving one packet. If your
implementation also supports window size larger than 1 then you can
send those 2-3 CREATE_CHILD_SA request at the same time and then start
waiting reply to them.

Also why do you need those multiple Child SAs? What is the difference
between them. If they just have different Traffic Selectors, then you
could also consider combining all the traffic selectors to the one
Child SA. If they have different algorithms, then the question is why
do they need different algorithms? Why some one algorithm is not safe
for all of the them?

IKEv1 did have feature of negotiating multiple Child SAs in one
exchange, but that was not taken in to the IKEv2. I do not know any
implementation which properly supported that IKEv1 feature and I have
not seen anybody asking for that feature before this for IKEv2.

What is the use case you have that would require that feature?
-- 
[email-masked]

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Tue, 30 Aug 2011 17:33:47 +0530

Thanks Tero for the reply.

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.
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. This can be achieved by 4 CREATE_CHILD_SA
exchanges following IKE_AUTH specifying the rest of 4 [TUNNEL_ADDRESS].

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.

So, the exchange will become - 

IKE_AUTH - 
IKE_IP_I:500 -> IKE_IP_R:500)
    HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
    [IDr,]AUTH, SAi2, TSi [TSi], TSr [TSr], [N(TUNNEL_ADDRESS_LIST)]}
-->

                              (IKE_IP_R:500 -> IKE_IP_I:500)
                          <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                               SAr2, TSi [TSi], TSr [TSr],
[N(TUNNEL_ADDRESS_LIST)]}

[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.
There will be different traffic_selectors for different IPSec SA.

To club this idea for CHILD_SA might not be really beneficial if the
traffic selectors can be clubbed.
So for all CHILD_SAs we can have a single child accommodating all
CHILD's TS.

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.

Regards,
Prashant Batra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tero Kivinen
Sent: Tuesday, August 30, 2011 3:27 PM
To: Prashant Batra (prbatra)
Cc: [email-masked]
Subject: [IPsec] Multiple Child-SA in a single exchnage

What is the use case you have that would require that feature?
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Aug 2011 16:14:18 +0300

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

> 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

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. 

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

> 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-masked]