[tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)

[Yawning Angel]

On Fri, 7 Mar 2014 10:45:14 -0500
David Goulet <dgoulet at ev0ke.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140308/f522d1a9/attachment.sig>