[tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
-----------------------------------------------+---------------------------
 Reporter:  cohosh                             |          Owner:  cohosh
     Type:  task                               |         Status:
                                               |  needs_review
 Priority:  Medium                             |      Milestone:
Component:  Circumvention/Snowflake            |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  anti-censorship-roadmap-september  |  Actual Points:
Parent ID:                                     |         Points:  6
 Reviewer:  dcf                                |        Sponsor:
                                               |  Sponsor28-must
-----------------------------------------------+---------------------------

Comment (by cohosh):

 >     I restructured the protocol a bit to only send the session ID at the
 start. This work as long as we're using the WebRTC datachannel with full
 reliability, and I think it's worth doing for this very simple precursor
 to Turbo Tunnel. The reason for the change was to simplify the calls to
 NewSnowflake so we don't have to pass in the header we read in order to
 determine which SnowflakeConn the snowflake belongs to. The drawback to
 this is that the server has to remember to call ReadSessionID before
 calling Read (which should be straightforward because Read should only be
 called on a SnowflakeConn and at the start, the WebRTC connection doesn't
 belong to a SnowflakeConn yet.
 >
 >    Basically, throughout writing this, I've tried to keep the client and
 server as symmetric as possible so that we share most of the code. This is
 a bit different from the approach taken in Turbo Tunnel.

 Also noting that doing things this way means we can't use this version for
 multiplexing which is maybe more along the lines of what we want to solve
 the issues with SOCKS timeouts. The way this is done in Turbo Tunnel with
 including the session id as the first bytes sent in each write and the
 connection migration technique from applications like mosh is very nice.
 Packets can be sent by the client through multiple multiplexed channels
 and the receiving end sends their data through whichever channel they most
 recently received data from.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29206#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online