Correct way of setting the TCP max segment sizes for IPv4 and IPv6?
Hi,
I have been looking at some firewall hardening examples which suggest setting the TCP maximum segment sizes but they do it only for IPv4.
Looking at RFC 9293, §3.7.1, I see those MSS values are different for IPv6, so I am approaching this like this:
chain ingress {
type filter hook ingress device "eth0" priority -500; policy accept;
# ...
# IPv4
meta protocol ip tcp flags syn tcp option maxseg size < 536 drop
# IPv6
meta protocol ip6 tcp flags syn tcp option maxseg size < 1220 drop
}My questions:
1. Is this the correct way to do this?
2. Is it good to do this (setting TCP MSS) at all?
3. Which is better and why:
meta protocol ip tcp flags syn tcp option maxseg size < 536 drop
or
meta protocol ip tcp flags syn tcp option maxseg size 1-535 drop
4. How do I test if this works correctly? (Debian 12 here)
Dňa 8. apríla 2024 19:24:41 UTC používateľ "William N." <[email protected]> napísal:
Quoted 2 lines
Looking at RFC 9293, §3.7.1, I see those MSS values are different for IPv6, so I am approaching this like this:
I decided do not bother with that and i use common limit for both versions.
regards
Signature · 2 lines
Slavko https://www.slavino.sk/
Quoted 2 lines · On Tue, 09 Apr 2024 18:43:58 +0000 Slavko wrote:
I decided do not bother with that and i use common limit for both versions.
But how do you know what that limit is? What about the RFC?
Dňa 9. apríla 2024 19:33:00 UTC používateľ "William N." <[email protected]> napísal:
Quoted 1 line
But how do you know what that limit is? What about the RFC?
RFC 9293, sect. 3.7.1
AFAIK main problem of too low MSS is CPU increase, using IPv4 limit for both solves corner cases...
regards
Signature · 2 lines
Slavko https://www.slavino.sk/
Quoted 1 line · On Tue, 09 Apr 2024 22:04:41 +0000 Slavko wrote:
RFC 9293, sect. 3.7.1
By asking "What about the RFC" I didn't mean "Which RFC sets the numbers". I meant "Why do you use the same MSS for IPv4 and IPv6, considering the RFC explains they are different?"
Quoted 1 line
AFAIK main problem of too low MSS is CPU increase,
This is how I understand it too. Wikipedia calls it "protocol overhead". I don't know if there are other implications though (e.g. OS fingerprinting or something else).
Quoted 1 line
using IPv4 limit for both solves corner cases...
How? The two corner cases are different and 1220 is > x2 than 536, i.e. very far from the "corner" (limit), i.e. it would not improve efficiency.
Dňa 10. apríla 2024 15:48:51 UTC používateľ "William N." <[email protected]> napísal:
Quoted 3 lines
By asking "What about the RFC" I didn't mean "Which RFC sets the numbers". I meant "Why do you use the same MSS for IPv4 and IPv6, considering the RFC explains they are different?"
Ah, OK, see next...
Quoted 3 lines
How? The two corner cases are different and 1220 is > x2 than 536, i.e. very far from the "corner" (limit), i.e. it would not improve efficiency.
I am far from TCP nor Linux kernel expert, and my English is limited...
But I understand that "overhead" problem as more worse with lower number. Thus MSS=1 is worse than eg. MSS=535 and that is worse than eg. MSS=1219.
The 536/1220 are not minimal allowed, but defaults if no MSS is send... Thus lower values are valid, only often not wanted... And i guess too, that lower (as defaults) MSS are worse in IPv4 than in IPv6, as IPv6 doesn't support fragmentation, thus only segmentation happens.
Finally, any FW rule adds overhead too (to packet processing), which can be neglible in this case, but happens. Any FW rule requires maintenance, that is overhead too (while not in packet processing), etc, etc.
When i consider these (and perhaps some more), i decided to not bother with two different values.
I can be wrong, but i used FWs without any MSS rule for years (decades), and i didn't notice any problem, and i learned already that sometime to be too smart can be worse than do not act at all . But i was not target of any real (D)DoS yet, only some kind(?) attempts (to be honest).
regards
Signature · 2 lines
Slavko https://www.slavino.sk/
I see what you mean. Thanks for clarifying. Hopefully someone more knowledgeable may enlighten us both :)