On 10/17/23 9:48 AM, Kuniyuki Iwashima wrote:
From: Martin KaFai Lau <martin.lau@xxxxxxxxx>
Date: Mon, 16 Oct 2023 22:53:15 -0700
On 10/13/23 3:04 PM, Kuniyuki Iwashima wrote:
Under SYN Flood, the TCP stack generates SYN Cookie to remain stateless
After 3WHS, the proxy restores SYN and forwards it and ACK to the backend
server. Our kernel module works at Netfilter input/output hooks and first
feeds SYN to the TCP stack to initiate 3WHS. When the module is triggered
for SYN+ACK, it looks up the corresponding request socket and overwrites
tcp_rsk(req)->snt_isn with the proxy's cookie. Then, the module can
complete 3WHS with the original ACK as is.
Does the current kernel module also use the timestamp bits differently?
(something like patch 8 and patch 10 trying to do)
Our SYN Proxy uses TS as is. The proxy nodes generate a random number
if TS is in SYN.
But I thought someone would suggest making TS available so that we can
mock the default behaviour at least, and it would be more acceptable.
The selftest uses TS just to strengthen security by validating 32-bits
hash. Dropping a part of hash makes collision easier to happen, but
24-bits were sufficient for us to reduce SYN flood to the managable
level at the backend.
While enabling bpf to customize the syncookie (and timestamp), I want to explore
where can this also be done other than at the tcp layer.
Have you thought about directly sending the SYNACK back at a lower layer like
tc/xdp after receiving the SYN? There are already bpf_tcp_{gen,check}_syncookie
helper that allows to do this for the performance reason to absorb synflood. It
will be natural to extend it to handle the customized syncookie also.
I think it should already be doable to send a SYNACK back with customized
syncookie (and timestamp) at tc/xdp today.
When ack is received, the prog@tc/xdp can verify the cookie. It will probably
need some new kfuncs to create the ireq and queue the child socket. The bpf prog
can change the ireq->{snd_wscale, sack_ok...} if needed. The details of the
kfuncs need some more thoughts. I think most of the bpf-side infra is ready,
e.g. acquire/release/ref-tracking...etc.
