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

[David Goulet]

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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140307/3b0c7956/attachment.sig>