Hi David,
I've also inlined my responses.
On 06/30/2017 09:08 PM, David Schinazi wrote:
Hi Vlad,
Responses inline.
On Jun 30, 2017, at 06:56, Vladimir Olteanu
<[email protected] <mailto:[email protected]>> wrote:
Hey David,
Thanks for the kind words. I'll address your questions inline:
On 6/29/2017 9:09 PM, David Schinazi wrote:
Hi Vladimir,
Thanks for writing this up, I agree SOCKS needs to be modernized and
I think your draft
has a lot of good ideas. A few questions:
- Why do you mimic the TFO semantics so closely?
Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning
of the initial data offset.
The server can pull enough data for the upstream TCP SYN from its
initial window
and leave the rest of the SOCKSv6 initial data there for later,
instead of resending it twice.
The main idea is to let the client send some data before running the
authentication protocol. The initial data offset gives the server a
carte blanche as to how much of the initial data it buffers while
waiting for the client to authenticate. (It still must read all of it
from the TCP stream before getting to the part where the client
proves its credentials.) Were it not for the authentication phase,
these fields would indeed be useless.
[DS] That makes more sense, thanks!
What's the benefit of sending the idempotent data before auth? The
proxy's not going to send it out
until it has received the last client -> proxy auth message so we may
as well send the data right after that?
(That said I'm not very familiar with GSSAPI or the non-standard auth
methods 3-8 so I could be missing something)
The core issue is that the client can start sending regular data only
when it is sure that the server won't ask for more authentication
information. If 0-RTT authentication is successful, the proxy can open
the socket right after the request, but the client has to wait 1 RTT
before finding out if it must go through the slow authentication process
or not.
- Does it make sense to keep sending the version number over the wire?
Proxy protocols need to be provisioned out of band (e.g. SOCKS vs
HTTP, port number)
and there is no way for a SOCKSv5 server to reply "I don't speak
SOCKSv6".
I'm not sure I see the value of a minor version either, as there's
still plenty of room
for major versions 7-255.
I think version numbers still make sense. When presented with a
SOCKSv6 request, a v5 proxy must at least know that the client is
speaking some other protocol. I will add a way for the proxy to
signal that it doesn't speak SOCKSv7+ in the next version of the
draft. Version numbers in operation replies don't make sense; I'll
remove those. As for minor versions, they might indeed be overkill,
given that v6 is extensible via options.
[DS] Wouldn't it be simpler to have IANA allocate a new port number
though?
One byte isn't a huge win but it does make implementations simpler.
The version byte helps with misconfiguration issues. Imagine what would
happen if the client and the proxy were to speak different versions
without either of them realizing. As for the amendment to the draft, it
won't really complicate matters. It will consist of the proxy saying
"but I speak version 6" and the client closing the connection.
- Instead of having a command code enum with 3 values and a TFO enum
with 2 values,
could we instead add a CONNECT_WITH_TFO command code to save a byte?
We could even take that one step further and also merge in the
address type enum.
This is certainly worth considering. Alternatively, we could use a
bit field: 2-3 bits for the command code, one bit for TFO, 2 for
address type etc. Otherwise, we might end up with too many command
codes (connect/bind x TFO x address type x whatever else we want to
cram in).
[DS] A bit field can be very useful, but not when some combinations
are not allowed.
For example having both TFO and UDP does not make sense. It does make
sense for
TCP/UDP/TFO vs IPv4/IPv6/hostname though.
I don't really see a problem with invalid bit group combinations. There
are other field combinations that also don't make sense (e.g. UDP and
initial data > 0).
- One pain point I had when implementing SOCKSv5 was the fact that
the port number
was after the address which meant that it moved, would it make sense
to place it before
the variable length address field to simplify and optimize parsing?
I don't see why not.
- Could we make the client supported auth methods optional?
Since the client is sending tentative auth proposals as options, one
could imagine
making the list of supported auth methods an option, an treating it
as "I only support
no auth" when it's not there
I like this idea. A side effect of this approach is that we move
another variable-length field to the back of the request, further
simplifying parsing.
- Out of curiosity, what specific use case are you using this
protocol for?
We are looking into using MPTCP on mobile devices to "bind" 4G/LTE
and WiFi. Mobile data networks have high latency, hence the drive to
shave off as many RTTs as possible and to take advantage of TFO, at
least on the client-proxy leg.
Cheers,
Vlad
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
