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 protected] [mailto:[email protected]] On Behalf
Of Tero Kivinen
Sent: Tuesday, August 30, 2011 3:27 PM
To: Prashant Batra (prbatra)
Cc: [email protected]
Subject: [IPsec] Multiple Child-SA in a single exchnage
Prashant Batra (prbatra) writes:
> 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.
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 protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
