Hi,
On Mon, 2023-12-04 at 08:52 +0000, Pierre Pfister (ppfister) wrote:
>
> So far, we have received feedback from people supporting our work, and
> sharing the same need. I'd like to encourage those people to take part in
> this thread.
>
basically, I can only reiterate the arguments we have already written down in
draft-mrossberg-ipsecme-multiple-sequence-counters, but there are two aspects I
would like to point out:
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.
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.
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.
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.
Regards
Michael
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
