TCPOPTSTROP can be repalced with undocumented "reset tcp option opt"

TCPOPTSTROP can be repalced with undocumented "reset tcp option opt"

[Niklas Beierl]

Hello,

I found myself in the situation of needing the behavior from the legacy  
TCPOPTSTRIP target. On the netfilter wiki, this target is listed under 
"Unsupported extensions" with the very brief comment "consider native 
interface, need to extend nft_exthdr.c".

https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables#TCPOPTSTRIP

The only other official resource I found regarding tcp option mangling 
is a section on the page "Mangling packet headers" which exclusively 
concerns itself with clamping TCP MSS to PMTU.

https://wiki.nftables.org/wiki-nftables/index.php/Mangling_packet_headers

I figured that it doesn't make sense that there is code that can handle 
this specific use-case but can't mangle tcp options in general. So I 
took to reading in the netfilter code a bit. I discovered that there are 
more registered keywords regarding tcp options and manipulating them, 
played around a bit and discovered that these statements have the 
foreseeable effect:

tcp option timestamp tsecr set 0
tcp option timestamp tsval set 0

Furthermore, I discovered this statement:

reset tcp option OPT

which seems to turn the selected option into NOPs. To my understanding 
this is equivalent to  "-p tcp -j TCPOPTSTRIP --strip-options OPT". Some 
superficial testing confirmed this. There also seem to be some "known" 
options: timestamp, window, sack-permitted, sack, md5sig and one can 
also target options using their numeric identifier for reset.

I think this should be mentioned in the wiki on the Mangling packet 
headers page and also with regards to replacing TCPOPTRESET. How can I 
make this happen? Can I get credentials to the wiki somehow? Should I 
instead write it up and send it to someone?

Furthermore, I would like to understand (and document) the general 
syntax for setting tcp options. I am especially curious whether tcp 
options can also be set if the field is not known to the netfilter code. 
I guess there are issues with encoding the cli-passed value 
appropriately in the header field?

Lastly I was wondering whether it is also possible to add or entirely 
remove option fields from tcp headers - as opposed to just NOPing them?

Best

Niklas

Re: TCPOPTSTROP can be repalced with undocumented "reset tcp option opt"

[Florian Westphal]

Niklas Beierl <niklasbeierl@posteo.net> wrote:
> I found myself in the situation of needing the behavior from the legacy  
> TCPOPTSTRIP target. On the netfilter wiki, this target is listed under 
> "Unsupported extensions" with the very brief comment "consider native 
> interface, need to extend nft_exthdr.c".
> 
> https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables#TCPOPTSTRIP

I've removed this bit, its outdated.

> reset tcp option OPT
> 
> which seems to turn the selected option into NOPs. To my understanding 
> this is equivalent to  "-p tcp -j TCPOPTSTRIP --strip-options OPT".

It is.

> I think this should be mentioned in the wiki on the Mangling packet 
> headers page and also with regards to replacing TCPOPTRESET. How can I 
> make this happen? Can I get credentials to the wiki somehow? Should I 
> instead write it up and send it to someone?

You could send a patch for iptables, specifically
extensions/libxt_TCPOPTSTRIP.c and add ".xlate" support together with a
libxt_TCPOPTSTRIP.txlate file (with tests).

Then the wiki could link to that just like it does for other supported
extensions.

> Furthermore, I would like to understand (and document) the general 
> syntax for setting tcp options. I am especially curious whether tcp 
> options can also be set if the field is not known to the netfilter code.

Whats your use case?

You can do
tcp option @255,8,8 255

(locate option 255, offset 8 bit, fetch 8 bits), then compare to 255.
Same syntax as raw payload expressions.

> I guess there are issues with encoding the cli-passed value 
> appropriately in the header field?
> 
> Lastly I was wondering whether it is also possible to add or entirely 
> remove option fields from tcp headers - as opposed to just NOPing them?

Not at this time, its more expensive since data needs to be moved.
NOPing is much simpler.