On Wed, 15 Nov 2023, Yoav Nir wrote:
Do you think it be better for each end to announce a maximum ahead of time?
(At negotiation of the first child SA)
I think so, but not completely sure.
Suppose one peer is willing to go to 32 parallel SAs, while the other is going
to stop at 8, because one has 32 cores and the other 8.
So on the “big” gateway, all flows that fit the TS should be forwarded to one
of 8 cores. If this was negotiated upfront, the big gateway can choose which 8.
As it is, the first 8 cores that triggered the negotiation get SAs, while the
rest have to forward after a short delay while trying and failing to negotiate
an SA.
Maybe it’s not an issue because SAs can be moved among cores. The draft
mentions this possibility.
We tried this approach but it runs into a lot of corner cases if
implementations try to closely match a very low number. Instead,
just let it run and treat the TS_MAX_QUEUE as a very high "sanity"
found. Maybe 256 or 1024 or even 10k if you only worry about DDoS.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
