Michael Pfeiffer writes:
> 1) The main effort for "full" child SAs is not only setting them up,
> but to maintain them (rekeying, monitoring, sending heartbeats and
> the like). In our experience, this becomes especially bad when
> partial failures are possible, i.e., a strict subset of the child
> SAs may fail. This could happen due to, e.g., on-demand child SA
> creation, or if NAT-T maps the child SAs to different UDP ports and
> a misconfigured firewall drops some of the flows.
NAT-T is a property of the IKE SA, and all Child SAs are going to use
the same UDP source and destination ports, so only way child SAs might
be using wrong port is if the IKE SA port numbers are not properly
propagated to all Child SAs, but that is implementation bug and should
not happen.
Also I do not understand what you mean by "sending heartbeats"? If you
are talking about the NAT Keepalives, they are again property of the
IKE SA, thus all child SAs do share keepalives, and there is only ever
need to send them if every single Child SA has been silent over NAT
keepalive period. If using default NAT keepalive period of 20 seconds
that means that IKE daemon needs to poll all cpus every 20 seconds to
see if there are any childs for each of their IKE SAs that has not
sent any packets since last poll. This operation depends mostly on the
number of IKE SAs, and immediately when it finds one cpu that has sent
out any packets on any of the Child SAs associated to the IKE SA, it
can bail out, and ignore sending of keepalive.
Note, that recipient of NAT keepalive does not matter, as you MUST NOT
do anything based on them. Also this only affects devices which are
BEHIND nat, i.e., most bigger security gateways will not be behind
NAT, while the clients connecting to them are behind NAT.
Rekeying, monitoring etc is something you need to do anyway, I do not
think there is that big difference there. It might even be simplier
with separate Child SAs as you do can do byte counting on the CPU that
contains the Child SA, with subspaces you need to collect summary of
number of bytes transmitted over all of the subspaces while counting
whether the Child SA needs to be rekeyed or not.
> 2) Regarding the hardware discussion, the main problem is not the
> interconnections between large sites, e.g., data centers
> ("network-to-network", as Ben calls them). Those are usually large
> devices with plenty of computing power on both sides and
> high-bandwidth links in between, so multiple child SAs may be used
> there.
>
> The in our opinion pathological cases are the SAs between large
> sites and very small sites (low-power gateways for small offices,
> notebooks, or mobile phones), so a typical access scenario. In this
> case, we have two options:
>
> a) Using a "classical" single child SA to the small site. But on the
> large gateway, we usually cannot control on which cores the
> plaintext traffic flows for that SA are received, as they are chosen
> by RSS. This means we either need to sync sequence counters between
> cores, or move the flows to the single core responsible for the SA.
> Both have a significant negative impact on the overall performance
> of the gateway.
On the other hand if the other end is "small site" by definition then
the bandwidth needed is most likely also smaller, i.e., if the other
end can't cope with creating multiple Child SAs because it is so
small, then having only one core taking care of traffic to that site
is not an issue. The one core can easily take care of that, if the
small site is able to process that data on its one core...
I do assume you already have a efficient way of routing traffic inside
your machine to correct core having Child SA for that traffic. You
most likely want to keep same flows on same Child SAs anyways.
> b) Using one child SAs for every core of the large gateway. This
> means we do not need to sync sequence numbers or move flows anymore,
> but have shifted the problem to the small device. There, we now need
> to set up, rekey, and monitor, say 64 SAs for the cores. Depending
> on the scenario, this number may easily be multiplied by 4-8 for QoS
> and doubled again for redundancy or multipathing. The problem
> becomes especially bad for battery-powered devices such as notebooks
> or mobile phones.
Are you assuming this small site is connected to just one large site,
or is this going to be full mesh thing? If small site is only
connected to one site, then having the small site processing few
hundreds of SAs should not be an issue. At least old Pentium PCs we
run tests on 20 years ago could do it, so I assume modern systems can
also do it. The number of Child SAs were never really an issue, the
issue was that they could not do the encryption on the line speeds,
and that was was slowing them down.
Notebooks, and mobile phones are usually not connected with gigabit
links, and are not able to encrypt/decrypt data on that speeds
anyways. In those cases the amount traffic is the important factor,
not the few tens of kilobytes of memory that is need to store all
those Child SAs, and the one table lookup based on the SPI to find the
correct entry on the SAD table for incoming traffic.
And you do not need to sync sequence numbers, as each of the Child SAs
have separate sequence numbers. Replay window syncing can be omitted,
if you simply disable replay checks.
> So for our use cases, multiple child SAs are a step in the right
> direction, but for example for the scenario outlined above,
> something like subspacing would allow us to run the large gateway
> with maximum performance while keeping the impact on the smaller
> device minimal.
For Arduino class devices the number of SAs might be an issue, but
anything more powerfull that Raspeberry PI should be able to handle
few hundreds of Child SAs without issues.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
