[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
-----------------------------------------------+---------------------------
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 This is finally ready for another review. Here's a rebased branch:
 https://github.com/cohosh/snowflake/compare/sequencing The main
 improvements from the last version are:
 - Each end of a SnowflakeConn will send empty acknowledgement packets
 (consisting of just the Snowflake header) upon the receipt of new data
 - Each write method spins up a goroutine that will wait for some specified
 time until checking to see if the acknowledgement packet for that data has
 been received. If not, it closes the underlying connection causing future
 reads and writes to fail.
 - On each call to SnowflakeConn's write method, data is saved in an
 internal buffer until it has been acknowledged
 - SnowflakeConn now has a new method to set and reset the underlying
 connection. If there is buffered data, SnowflakeConn will resend that data
 under the same session ID whenever a new underlying connection has been
 specified

 My reasoning for implementing it this way is that the client and server
 shouldn't have to worry about buffering data after a call to Write(). This
 makes
 [https://github.com/cohosh/snowflake/blob/sequencing/client/lib/webrtc.go#L34
 the buffer in `client/webrtc.go`] redundant, but I'll remove it later when
 finishing up tying together the client and server interactions.

 The next step of course is to allow for resetting the underlying
 connection in SnowflakeConn and using the sessionID to correlate new
 connections with old ones. There's going to have to be some tricky
 refactoring here. Right now when the webrtc connection times out (due to
 staleness), both the webrtc connection and the socks connection are closed
 and the client waits for a new socks connection to open. The SnowflakeConn
 should be persistent across snowflakes (and the way it is currently set up
 perhaps also across SOCKS connections (??)), so the question is where
 SnowflakeConn should "live".

 I'm thinking of adding a new method to SnowflakeCollector that will set
 (and reset) the underlying connection, and then modifying the
 [https://github.com/cohosh/snowflake/blob/sequencing/client/lib/snowflake.go#L24
 Handler function] to redefine the snowflake rather than closing the SOCKS
 connection and waiting for a new one. This doesn't fit perfectly with what
 I'd assume a SnowflakeCollector does by name, but then again maybe it
 does. This would make the SnowflakeCollector responsible for both getting
 new snowflakes and also deciding which snowflake(s) to send traffic
 through.

 Any feedback on decisions up to this point and on future plans is welcome
 :)

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