Kuniyuki Iwashima wrote: > Under SYN Flood, the TCP stack generates SYN Cookie to remain stateless > for the connection request until a valid ACK is responded to the SYN+ACK. > > The cookie contains two kinds of host-specific bits, a timestamp and > secrets, so only can it be validated by the generator. It means SYN > Cookie consumes network resources between the client and the server; > intermediate nodes must remember which nodes to route ACK for the cookie. > > SYN Proxy reduces such unwanted resource allocation by handling 3WHS at > the edge network. After SYN Proxy completes 3WHS, it forwards SYN to the > backend server and completes another 3WHS. However, since the server's > ISN differs from the cookie, the proxy must manage the ISN mappings and > fix up SEQ/ACK numbers in every packet for each connection. If a proxy > node is down, all the connections through it are also down. Keeping a > state at proxy is painful from that perspective. > > At AWS, we use a dirty hack to build truly stateless SYN Proxy at scale. > Our SYN Proxy consists of the front proxy layer and the backend kernel > module. (See slides of netconf [0], p6 - p15) > > The cookie that SYN Proxy generates differs from the kernel's cookie in > that it contains a secret (called rolling salt) (i) shared by all the proxy > nodes so that any node can validate ACK and (ii) updated periodically so > that old cookies cannot be validated. Also, ISN contains WScale, SACK, and > ECN, not in TS val. This is not to sacrifice any connection quality, where > some customers turn off the timestamp option due to retro CVE. If easier: I think it should be possible to make the host secret readable and writable with CAP_NET_ADMIN, to allow synchronizing between hosts. For similar reasons as suggested here, a rolling salt might be useful more broadly too.
