On 07 Mar (14:03:35), Yawning Angel wrote:
Sorry this response took so long. I've been kind of busy.
On Sat, 01 Mar 2014 13:57:34 +0100 "Sebastian G. <bastik.tor>" bastik.tor@googlemail.com wrote:
To me it is clear that the two are messed up, but I'm not sure what's the correct order.
Indeed. Since there isn't a clear advantage to going one way or another for this, 0xE0 should be not found, 0xE1 should be not available.
Looking at some of the stuff nickm added:
What should a client if it gets a value here it does not recognize? (wrt status code in the response from the server)
All response codes that are not 0x00 are defined as a failure state, and the server is required to drop the connection after sending one. I'm not sure client behavior needs to be specified here.
Quoting rfc1928:
"When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure."
So what about simply terminating the connection which I guess would be a fourth option "Close" ?
What do these do? What is their behavior? Are they client-only? (wrt The USERNAME/PASSWD keys that are reserved)
My intention was to reserve keys required to add support for doing RFC1929 style authentication if we desire in the future that is separate from whatever other keys we decide to use in the future. (As a "Yes, these actually for a username/password, don't abuse them for other things"). Client-only, unless reserving this isn't useful (It might not be, there was some grumbling about one day supporting authentication again). "PASSWD" should be "PASSWORD" instead here I guess (or "USERNAME" should be "UNAME" to be consistent with RFC1929).
What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response)
There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible.
Same as above.
Should we recommend any namespace conventions for these?
Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc?
Would this be *appended* to a client given key like for instance "myapp1:tor.streamIsolation" or it would be a hardcoded string key that the client needs to use in order to enable the "feature".
I can see one use for having custom keys along with a name space which is to having a way to identify the SOCKS connection on the control port for knowing in which country the exit is for instance (or whatever info you need). The source port can be use for that but for an external client not knowing it, it might be interesting to be able to ask the control port "What's the exit node of <INSERT_KEY> SOCKS connection".
Cheers! David
Actually, should this perhaps be controlled by additional KEY? (re: Response codes).
I don't think this is necessary. Explicitly specifying that after sending/receiving a status code that is not 0x00 (Defined as Success in RFC1928, the server/client MUST drop the connection should be sufficient? (I'm not sure either)
Regards,
-- Yawning Angel
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev