calculating shadowsocks overhead (maybe reducing it :-) ?) [question]

[LindaFerum]

So, wireguard over shadowsocks, and the overhead is slightly not what I expected.

Ping-based estimation of maximum viable wg0 MTU is 1392

but shadowsocks UDP as per what I've been able to read introduces 32 byte overhead (including encryption tag and address to which encrypted UDP is to be forwarded.
Under that we have 40 byte wireguard overhead, and on top of that an extra layer of UDP+IP4

so, 40+32+8+20 is 100

Should amount to a viable MTU of 1500-100 = 1400, right?

Question:
Where have 8 bytes gone?

Question 2
Does deprecated encryption from stream-cipher feature interact amicably with current shadowsocks UDP spec (2022-1-shadowsocks-2022-edition.md) ?

Question 2.5 if it does, would it cut down on overhead (16 byte tag should be gone then, no?) ?

I know it sounds petty :) but this is not the last layer being encapsulated in that connection (and software at the "lowest layer" is fussy about seeing a network device with MTU <1300 lol)

wireguard does its own AEAD stuff, shadowsocks is primarily being employed to provide obfuscation and "add-a-hop" functionality... and I could really use saving 16 bytes or more.

[database64128]

Shameless plug: You might be interested in https://github.com/database64128/swgp-go.

[LindaFerum]

Thanks! Really cool work.

Guess I won't be able to use it in this project tho.

I need first hop to be to a "general purpose VPN" that allows config download, so the proxy server must be agnostic with regards to final destination server's whereabouts (no pre-set wgEndpoint one could say) and the destination server is similarly agnostic towards the (very existence of) proxy

Running wireguard through shadowsocks's TUN does exactly that and works decently so far (ehhh, aside for the 108 byte overhead, sigh)
I guess the fine gentlemen (spit) doing internet filtering here can spend only so much effort detecting VPN traffic for now... (or maybe the fact there's a decoy website on 443 and 80 is helping)

[zonyitoo]

If you do care about the overhead and don't want any encryption in protocol, you can use the none cipher method.

[LindaFerum]

Well, that was about first thing I tried but after a while such connections started breaking down and matters improved only after I turned on encryption and changed server's IP (AWS yes)

probably encrypting with an imperfect encryption scheme (for purposes of obfuscation only) should be fine too - maybe even RC4 would do (tho with AES-NI using aes-128-ctr should be comparably fast and appreciably more robust, I presume) but I just wonder if the legacy schemes are being maintained at all / can be assumed to interact in "expected manner" with current shadowsocks spec (not to break, obfuscate adequately, and actually achieve some degree of overhead reduction)

Seems like one of those things one should ask first :-)

[zonyitoo]

The stream ciphers are all marked as "deprecated" because the stream protocol is already proved to have inherent weakness. Document already said they will be removed soon.

In this project, stream ciphers are still there but disabled by default.

Stream protocol will have less overhead in UDP protocol, because it only contains an IV and target addresss. If you understand the security flaw of the stream protocol and then do your own choice, you could try to compile it with --features "stream-cipher" and see if it actually help to solve your problem in your environment.

[LindaFerum]

Thanks !