Max Lv

For a client, ping-pong bloom filter should be good enough. Although we call it short-term replay avoidance, it usually takes weeks to flush the filter for a client. Right, swapping...

@Mygod You're assuming different clients share the same key?

Okay, you mean the clients connected to the same server port. Yes, you're right.

I think we can draft a protocol upgrade for this, like what we did before in SIP004 and SIP007. Several guidelines: 1. Minimize the protocol change and packet overhead. 2....

@zonyitoo I think a protocol upgrade should solve the replay issue entirely. Something like session ID can be introduced. Moving to TLS based SOCKS6 protocol can solve everything, but that's...

@Mygod Yes, I think your solution is straightforward for TCP. But for UDP, we have multiple and out-of-order IV/nonce from client, which makes the implementation complicated. I agree that the...

IMO, adding something like session ID should be acceptable, as the overhead is negligible. Let's see what's the proposal from @DuckSoft and others. Hope it can make most of people...

NAT should not be a problem, as long as not all of the users are behind the same NAT address. Say five users behind a same NAT ip address, at...

This SIP just suggests a kind of multi-user-single-port solution for shadowsocks without modifying the protocol. But as mentioned by @Mygod, shadowsocks is not designed for this purpose. I listed this...

Fallback lookup is always needed. Even a key is cached, the authentication is still required. If failed for authentication, a fallback lookup is performed. I don't expect millions of users...