Hi Vlad, Responses inline.
> On Jun 30, 2017, at 06:56, Vladimir Olteanu <[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) >> - 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. >> - 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. >> - 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. Thanks! This is cool work. David Schinazi
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
