On Fri, 7 Mar 2014 10:45:14 -0500 David Goulet <dgoulet@xxxxxxxxx> wrote: > 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" ? This is for the auth status, which is different from the RFC1928 REP. But as you point out, the behavior set down for the server is the same as when a non 0x00 REP value is sent. Client behavior is undefined, but since the server will close, it doesn't matter (We could be the better spec and state that clients MUST close). > > * 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. Hmm, ok. I thought it would be nice to allow older clients to interoperate with newer servers that potentially send back more information in the response, but I suppose that isn't required (when we add more key/value pairs that get sent in the response, we can define them to only be sent if the client requests them"). So Close/Drop sounds reasonable here. > > * 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 was thinking the latter "myProtocol.myConfigSetting". So for example, every TBB connection would send "tor.sessionIsolation"/"Some Session ID", every ScrambleSuit pt client would send "scramblesuit.password"/"Base32 encoded k_B" etc. This model makes arg handling with nested socks client/server pairs fairly easy as well (Think Tor->ScrambleSuit->Meek as a example), since each step can strip off the args it handled and forward the rest to the next SOCKS proxy in the chain. Not sure if the inability to nest multiple invocations of the same protocol is a problem (Tor->ScrambleSuit->obfs3->ScrambleSuit would not work because 2 "scramblesuit.password" keys need to be sent). Back to the forward compatibility thing, we could also define "tor.optional", for things that can safely be ignored if not understood. Not sure if such things exist (most of the things I can think of for key/value pairs are mandatory). > 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". Is a custom key needed for this? The query you used as an example could just as easily be done without any SOCKS extensions as "What's the exit node of <Insert Source Address/Port> SOCKS connection" couldn't it? One final open question, are there any other status codes that people think should be defined beyond the HS ones and the PT ones? Regards, -- Yawning Angel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev