While the SACK Scoreboard in the base stack limits
the number of holes by default to only 128 per connection
in order to prevent CPU load attacks by splitting SACKs,
filtering out SACK blocks of unusually small size can
further improve the actual processing of SACK loss recovery.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I'm wondering if it would be better to require that the sack block covers at least mss - 40 bytes. We don't know if we sent a SACK or AccECN option and it doesn't make sense to ignore the SACK blocks corresponding to such packets we sent not performing an attack.
Comment Actions
- filter out any segments smaller than the current maxseg size minus maximum tcp header options