SIP022: Shadowsocks 2022 Edition

[database64128]

• Main spec: https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md
• EIH: https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-2-shadowsocks-2022-extensible-identity-headers.md

[zonyitoo]

I would prefer EIH to be in another document, because it is not required for personal users.

[database64128]

Made some changes:

• Removed the EIH section.
• Added EIH spec in a separate document.

[database64128]

⚠️ Major breaking change

To have better defense against active probes, we made a breaking protocol change. Part of the header, specifically type and timestamp, now sits in the first "length" chunk. After this change, one read call is all it takes to determine whether the request is legitimate or not.

Before this change, the request header in its entirety is in the first payload chunk. Implementations also attempt to squeeze as much payload as possible into the first payload chunk. It is likely that the total size of the first write exceeds the capacity of a single TCP segment (under typical MSS). Therefore, it might take more than one read call to read the first payload chunk. To defend against probes that send one byte at a time, implementations usually drain the connection when an error occurs.

This behavior has several drawbacks. First of all, it is very uncommon for a TCP service to read infinitely. TCP services usually closes the connection when invalid data is received. Secondly, it opens the door for resource exhaustion attacks. Anyone can just connect and send an infinite amount of data, or send nothing but open a lot of connections.

With this change, draining the connection is no longer necessary, because on the first read either we have a valid header that you can tell whether it's replay, or the request is illegitimate. We can just forcibly close the connection if something is wrong. The other party does not get to know how many bytes the server has read, because no matter what you send, or how much you send, as soon as it's sent, the connection gets closed.

Spec change commit: Shadowsocks-NET/shadowsocks-specs@a6fe1a1

[qeatzy]

#183 (comment)

[SilverBut]

Without enough difference, it might be a hard job to make people realize Shadowsocks 2022 != Shadowsocks. This could make user suffer from the breaking change.

What about change to a better, more identifiable name, while maintaining the characteristics to show this protocol is sharing most design ideas from Shadowsocks? (But i have no good idea...)

Reading unlimited is surely a problem, but I think allowing unlimited idle connections is not what Shadowsocks protocol should care about, since anyone can open tons of connections on any TCP server. Let's leave this job to the protocol stack in kernel.

[codebylove]

TCP
Request stream:
+--------+------------------------+---------------------------+------------------------+---------------------------+---+
|  salt  | encrypted header chunk |  encrypted header chunk   | encrypted length chunk |  encrypted payload chunk  |...|
+--------+------------------------+---------------------------+------------------------+---------------------------+---+
| 16/32B |     11B + 16B tag      | variable length + 16B tag |  2B length + 16B tag   | variable length + 16B tag |...|
+--------+------------------------+---------------------------+------------------------+---------------------------+---+

Response stream:
+--------+------------------------+---------------------------+------------------------+---------------------------+---+
|  salt  | encrypted header chunk |  encrypted payload chunk  | encrypted length chunk |  encrypted payload chunk  |...|
+--------+------------------------+---------------------------+------------------------+---------------------------+---+
| 16/32B |    27/43B + 16B tag    | variable length + 16B tag |  2B length + 16B tag   | variable length + 16B tag |...|
+--------+------------------------+---------------------------+------------------------+---------------------------+---+

The TCP response stream started with the salt of the request stream, both request and response start with the same salt, will it make protocol easily detected?

[database64128]

@yzou The response stream uses a new salt.

[codebylove]

@database64128 Thanks, my mistake.

[FranzKafkaYu]

Hello developers,I noticed that you proposed a new url scheme——https://github.com/shadowsocks/shadowsocks-org/wiki/SIP002-URI-Scheme. But this will cause old shadowsocks url scheme not consistent with the new one and the downstream has to make more errforts to adaptation.Could you keep the same url scheme.It's convenient to users and also good to downstream.

[database64128]

@FranzKafkaYu It's not a new URL scheme. The plain method:password format without the extra base64url encoding has existed for a long time, and is well supported by many clients, including shadowsocks-android. We just standardized it this time because URLs are supposed to be human-friendly. Excessive and unnecessary usage of base64 encoding in URLs is a bad practice, and must be discouraged.

[codebylove]

About UDP relay, why is it necessary to open a new relay session(UDP socket) based on (source address, port), as there is a session id in the separated header and it's included in the server-to-client header? One client UDP socket is enough, map all:1 UDP connection.

To start a UDP session, the client generates a new random session ID and maintains a counter starting at zero as packet ID

About the packet ID, it should be a global counter, instead of a session packet counter, or else when a session expires on the server, the replay attack will pass the sliding window filter check.

[database64128]

why is it necessary

It's not necessary, but it's easier and much more efficient this way. With one UDP socket per session, your downlink (server -> client) relay loop only has to decrypt, authenticate, and forward packets for the current session. Multiple sessions can take advantage of multiple CPU threads. If you multiplex all UDP sessions into one UDP socket, the entire downlink can only use one CPU thread, and could easily become the bottleneck.

Nevertheless, servers are required to support UDP session multiplexing. So feel free to implement it if you like. :P

when a session expires on the server, the replay attack will pass the sliding window filter check.

This won't happen, because the packet header has a timestamp, and servers are required to have a NAT timeout of no less than 60 seconds. When a session expires, its packets won't pass the timestamp check.