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

[Yawning Angel]

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.

 * 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.

 * 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?

 * 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
-------------- 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/20140307/2daf0b80/attachment.sig>