Disabling TCP SACK, DSACK, FACK

https://www.suse.com/c/sles-1112-network-cpu-tuning-optimization-part-2/

Disabling selective TCP acknowledgments mandates also to disable corresponding related parameter, which is tcp_dsack and tcp_fack for specific packet type.

Maybe we should disable DSACK and FACK as well as SACK?

We’ve discussed SACK before:

http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/kernel-hardening/7296/55

How liekly is ti these other ACK types can be induced anyway?

They all seem to be some form of SACK or depend on SACK.

DSACK seems to stand for Duplicate Selective Acknowledgement (duplicate SACK).

We have developed a Forward Acknowledgment (FACK) congestion control algorithm which addresses many of the performance problems recently observed in the Internet. The FACK algorithm is based on first principles of congestion control and is designed to be used with the proposed TCP SACK option.

1 Like
1 Like

Even just net.ipv4.tcp_sack=0 causes grave issues with my clearnet connectivity. A usually 2 seconds page load time goes up to 10 seconds or so.

The problem is out style of development is rather early stage. We don’t have a testing farm of various computers in various configurations such as in globally distributed locations using different ISPs, different hardware, different routers, different configurations, running various automated connectivity and performance tests.

I am not calling it amateur because not even commercial operating systems might have that level of testing. However, without that level of testing we are flipping settings with very limited testing. Mostly just in our own configuration. With our computer, our ISP, our setup, etc. We’re kinda walking blind so to speak.

Therefore this change is too experimental to be applied by default for all users. Note: security-misc is a general, non-Whonix specific page.

I will merge this change to have it inside the git history and then undo it by deleting file /etc/sysctl.d/tcp_sack.conf.

If you like, this could be implemented on an opt-in basis. I.e. all files by default and the user only has to pull the trigger (run some command) to enable all of this.

Another alternative could be creating a package security-extra or so which I am happy to maintain in sense of hosting on github, adding to Whonix repository, review/merge etc. but not installed by default in Whonix or Kicksecure. This would however allow easy activation of this using sudo apt install security-extra or so and may also get installed by default when using some opt-in Whonix custom build parameter.

2 Likes

For reference, latest file before deletion:

1 Like
1 Like

For me, there isn’t a difference in speed.

We can probably make our own test suite, rent a few VPSes and test them after each change. VPSes are rather cheap nowadays.

It would be better to keep the file but have those lines commented out by default. If a user wants to disable SACK, they can just comment out that file and it can be documented in Whonix-Workstation Security Hardening - Whonix and the readme like the hardware info restrictions.

Sure. Done in git master.

That would be cool. Patches welcome.

Unfortunately nobody ever was interested in contributing in test suite / creating tests:

1 Like

I think this issue can now be closed as we have had SACK, DSACK, and FACK enabled by default for over 3 years?

1 Like

Yes, so just remove the comment and it’s done?

1 Like

Thanks, merged!