Re: [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:  closed
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  dcf |Sponsor:
|  Sponsor28-must
+--
Changes (by cohosh):

 * status:  needs_revision => closed
 * resolution:   => wontfix


Comment:

 Closing this now that turbotunnel has been merged (#33745)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  dcf |Sponsor:
|  Sponsor28-must
+--
Changes (by gaba):

 * keywords:  anti-censorship-roadmap-september => anti-censorship-roadmap-
 2020Q1


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 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_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 dcf):

 Replying to [comment:37 cohosh]:
 > Replying to [comment:36 teor]:
 > > Some users even struggle with Tor's 10-30 second timeouts, because
 they are on really slow links.
 > > Even mobile from Australia to Europe can take a few seconds.
 >
 > So Tor's timeout is 10-30 seconds?

 Hum, TIL tor has a
 [https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt?h=tor-0.4.1.6#n1376
 SocksTimeout] option. But it's supposed to be 120 s, not 30 s.
 >  SocksTimeout ''NUM''::
 >Let a socks connection wait ''NUM'' seconds handshaking, and ''NUM''
 seconds unattached waiting for an appropriate circuit, before we fail it.
 (Default: 2 minutes)

 I'm not sure where the 30 s is coming from. Could it be
 LearnCircuitBuildTimeout or something like that? Anyway, you could test
 using an artificially high SocksTimeout, to see if the problem still
 happens.

 Replying to [comment:38 cohosh]:
 > > Anyway, you can always send a fake "Grant" response without waiting
 for a proxy to be available
 > Snowflake does the same [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/snowflake.go#n31 here].

 No, what it's doing now is not quite what I mean. I mean putting the
 `socks.Grant` ''before'' the `snowflakes.Pop()` (or even inside
 `socksAcceptLoop`). If I'm not mistaken, `snowflake.Pop` is a blocking
 operation that doesn't return until an entire broker exchange has happened
 and a WebRTC connection is established. I mean optimistically calling
 `socks.Grant` on the incoming SOCKS connection immediately, even if we
 have 0 snowflakes available. Especially now that this sequencing branch
 exists, tor's SOCKS connection is not tied to any single WebRTC
 connection.

 > We could try sending data through a few proxies (maybe 3?) and then just
 use whichever snowflake gets the data to the server the fastest?

 Yes, I think this can work. (Something like IPv4/IPv6 "happy eyeballs.")
 My plan for a turbo tunnel adaptation is to basically do this, try sending
 through all available snowflakes at all times (using e.g. round robin),
 and if one doesn't work or drops packets, it's no problem. Even without
 multiplexing, you could race just the WebRTC rendezvous across 3
 snowflakes, then take the one that finishes first, and throw the others
 away.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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):

 > Is it the timeout when tor sends a SOCKS request and is waiting for the
 "Grant" or "Reject" response? With the Snowflake protocol in place, tor
 should not be requesting new SOCKS sessions anyway -- because snowflake-
 client won't be closing its existing SOCKS connection every time it loses
 proxy connectivity. Anyway, you can always send a fake "Grant" response
 without waiting for a proxy to be available; that's what meek does and the
 PT protocol kind of forces that behavior on non-connection-oriented
 protocols like this.

 Snowflake does the same [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/snowflake.go#n31 here]. It's
 timing out because after granting the request, the SOCKS connection hasn't
 received any data in 30s if the user happens to get a bad snowflake. The
 connection isn't been closed on the PT side, it's being closed on the tor
 side it seems. So unless there's some way for the PT to send some kind of
 keep alive signal, there's no way for the SOCKS connection to tell the
 difference between a connection that's gone completely dead for some
 reason.

 Perhaps multiplexing is the way to go. What I was asking for with the
 short timeouts was maybe a bit misleading. I was thinking of trying to
 cycle really quickly through bad proxies before landing on a good one but
 that still takes time and doesn't seem like the right approach here. We
 could try sending data through a few proxies (maybe 3?) and then just use
 whichever snowflake gets the data to the server the fastest?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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):

 Replying to [comment:34 dcf]:
 > In any case, 5 seconds strikes me as way way too short for a liveness
 timer. We'll be throwing away good proxies all the time. The fact that tor
 is requesting new SOCKS connections indicates that we're signaling some
 failure condition upward that we shouldn't be, I think; I would check that
 out first.

 Replying to [comment:36 teor]:
 > Some users even struggle with Tor's 10-30 second timeouts, because they
 are on really slow links.
 > Even mobile from Australia to Europe can take a few seconds.

 So Tor's timeout is 10-30 seconds? That seems like our problem here then.
 If the SOCKS connection to the PT closes after not being able to bootstrap
 in 10-30 seconds, then we only get one shot to bootstrap fully with the
 first snowflake we get. Otherwise the user gets a warning that there's
 something wrong with the network and has to restart the bootstrap process
 manually (which may again fail). Any thoughts on how to solve this other
 than multiplexing and trying to send the data through multiple snowflakes
 at once?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 teor):

 Some users even struggle with Tor's 10-30 second timeouts, because they
 are on really slow links.

 Even mobile from Australia to Europe can take a few seconds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 dcf):

 Replying to [comment:33 cohosh]:
 > Alright, I had a chance to take a look at the obfs4 integration with
 Turbo Tunnel:
 https://github.com/net4people/bbs/issues/14#issuecomment-544747519
 >
 > Another option is to just scrap the work done here so far and work turbo
 tunnel into snowflake.

 We talked about this at [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-10-24-16.59.html the last meeting] and decided to continue
 with snowflakeConn, because work on adapting Snowflake to a turbo tunnel
 scheme is at least a few months off.

 > I'm curious about whether Turbo Tunnel is going to be implemented as a
 separate library.

 No, I'm not planning anything like that. For one thing, turbo tunnel isn't
 a singular thing, it's more of a high-level design principle: putting a
 session/reliability layer in the middle of a circumvention protocol
 enables a lot of nice features. Even the connection migration stuff shown
 off in the obfs4proxy demo, I wouldn't call core to the turbo tunnel idea;
 it's just one of many things made possible. My second consideration is
 that I feel we're still in the phase of requirements gathering, which is
 accomplished by doing a series of non-reusable, concrete implementations.
 The likelihood of getting the API wrong is too high otherwise. With my
 software engineer hat on, I see a resusable library at this point as
 having both high risk and high cost.

 I am, however, planning to try implementing the turbo tunnel idea directly
 in Snowflake, as part of this whole process.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 dcf):

 Replying to [comment:31 cohosh]:
 > I made several changes to the implementation.
 [https://github.com/cohosh/snowflake/tree/sequencing2 Here] are a series
 of commits on top of the old branch, and
 [https://github.com/cohosh/snowflake/tree/sequencing2_squashed here] is a
 newly squashed version.

 Branch sequencing2 is missing server/flurry.go. sequencing2_squashed has
 it.

 
[https://github.com/cohosh/snowflake/blob/3a3bef35199d944464bf2e2bfa3e07d43ae7a2cc/common/proto/proto.go#L356-L361
 Here], it still looks like it should be `err2` inside the error handler,
 not `err`.
 {{{
 n, err2 := s.conn.Write(bytes)
 s.writeLock.Unlock()
 if err2 != nil {
 log.Printf("Error writing to connection: %s", err.Error())
 return len(b), err
 }
 }}}

 > > > Perhaps 10s is too long a timeout?
 > >
 > > I don't understand this. Do you mean too ''short'' a timeout? As a
 retransmission timer, 10 s doesn't seem short, but as a timer that
 terminates the whole end-to-end connection, it does seem short. Since in
 this design, there's no retransmission except when kicked off by a
 `NewSnowflake` transition, it might be worth increasing the timeout.
 >
 > You're right that 10s is short for a network connection timeout. This
 brings us to what remains to be a tricky engineering challenge here. The
 goal of the sequencing layer is to allow the client to recover from a
 faulty snowflake. However, it takes 30s for the connection to go stale in
 the client's `checkForStaleness` function. So it takes 30s for a client to
 request a new snowflake and start se nding data through it. In all of my
 tests, the SOCKS connection timed out well before the client connected to
 a new snowflake. Since a new SOCKS connection means a new snowflake
 session and new OR connection anyway, this means the client never actually
 recovers and the browser reports a connection error.
 >
 > So my thought was that if we lowered it to 10s, we have a chance to
 recover before the SOCKS connection goes stale. However in practice this
 is still a bit too long and I'm still seeing SOCKS timeouts.
 >
 > So, I'm wondering if it's ok if we make this even shorter. All it means
 is that the client will abandon the proxy connection for a better one with
 less latency and that the threshold for that can be low (maybe 2-5
 seconds).

 I guess I really don't understand how this works. How is the SOCKS
 connection timing out? As far as I know, tor does terminate connections to
 client PTs because of idleness. Is there a specific log message I can look
 for to see when this happens? snowflake-client should be hiding those
 temporary losses of connectivity.

 Is it the timeout when tor sends a SOCKS request and is waiting for the
 "Grant" or "Reject" response? With the Snowflake protocol in place, tor
 should not be requesting new SOCKS sessions anyway -- because snowflake-
 client won't be closing its existing SOCKS connection every time it loses
 proxy connectivity. Anyway, you can always send a fake "Grant" response
 without waiting for a proxy to be available; that's what meek does and the
 PT protocol kind of forces that behavior on non-connection-oriented
 protocols like this.

 In any case, 5 seconds strikes me as way way too short for a liveness
 timer. We'll be throwing away good proxies all the time. The fact that tor
 is requesting new SOCKS connections indicates that we're signaling some
 failure condition upward that we shouldn't be, I think; I would check that
 out first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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):

 Alright, I had a chance to take a look at the obfs4 integration with Turbo
 Tunnel: https://github.com/net4people/bbs/issues/14#issuecomment-544747519

 Another option is to just scrap the work done here so far and work turbo
 tunnel into snowflake.

 One of the main differences between Snowflake and obfs4 in how it relates
 to the work on Turbo Tunnel so far is the difference in how Dial would be
 called. There is no `Dial` in snowflake, but rather a simultaneous routine
 that collects snowflakes in the background until we are ready to use them.
 A call to a call to [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/snowflake.go#n20
 snowflakes.Pop()] retrieves it for use by the `Handler` function.

 I'm curious about whether Turbo Tunnel is going to be implemented as a
 separate library.

 Snowflake could accommodate this with a dial function similar to the one
 provided by the obfs4 ClientFactory:
 https://dip.torproject.org/dcf/obfs4/blob/reconnecting-
 quic/transports/base/base.go#L56
 Here `Dial` would likely be provided by `SnowflakeCollector` and just wrap
 the call the `snowflakes.Pop`. Then `dialAndExchange` could take a
 `Dialer` interface as the first argument.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:

 Replying to [comment:28 dcf]:

 Thanks! This feedback was very helpful. I made several changes to the
 implementation. [https://github.com/cohosh/snowflake/tree/sequencing2
 Here] are a series of commits on top of the old branch, and
 [https://github.com/cohosh/snowflake/tree/sequencing2_squashed here] is a
 newly squashed version. The main changes are:
 - 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.

 - I fixed the race conditions and found a bug that was causing a seg
 fault. The server now seems to be running consistently well without
 crashing.

 To address specific comments:
 > Could `Flurry.conn` be a plain `net.Conn`, and `Flurry.or` also? Or do
 they need the specialization to `*proto.Snowflake.Conn` and
 `*net.TCPConn`?
 Not the way I've written in right now because of the calls to
 `Flurry.conn.NewSnowflake`
 
[https://github.com/cohosh/snowflake/blob/sequencing_squashed/server/server.go#L186
 here]. I don't think generalizing this at the expense of complexity at the
 client is desirable, since Flurries are specific to Snowflake connections.
 > > I see some motivation for another feature that allows us to set some
 kind of FIN or RST flag to notify the client that the OR port has been
 closed and the server that the client has closed the connection.
 >
 > Yes, but in the Tor model, it essentially never happens that a
 relay/bridge closes an ORPort connection, right? It's usually the client
 that decides when to disconnect.
 The exception to this is if there is the client is giving the bridge bad
 data. Of course that '''shouldn't''' happen unless there is a bug in the
 client so maybe that's ok to just let time out. I think you're right here
 that this feature is unnecessary.
 >
 > > Perhaps 10s is too long a timeout?
 >
 > I don't understand this. Do you mean too ''short'' a timeout? As a
 retransmission timer, 10 s doesn't seem short, but as a timer that
 terminates the whole end-to-end connection, it does seem short. Since in
 this design, there's no retransmission except when kicked off by a
 `NewSnowflake` transition, it might be worth increasing the timeout.

 You're right that 10s is short for a network connection timeout. This
 brings us to what remains to be a tricky engineering challenge here. The
 goal of the sequencing layer is to allow the client to recover from a
 faulty snowflake. However, it takes 30s for the connection to go stale in
 the client's `checkForStaleness` function. So it takes 30s for a client to
 request a new snowflake and start se nding data through it. In all of my
 tests, the SOCKS connection timed out well before the client connected to
 a new snowflake. Since a new SOCKS connection means a new snowflake
 session and new OR connection anyway, this means the client never actually
 recovers and the browser reports a connection error.

 So my thought was that if we lowered it to 10s, we have a chance to
 recover before the SOCKS connection goes stale. However in practice this
 is still a bit too long and I'm still seeing SOCKS timeouts.

 So, I'm wondering if it's ok if we make this even shorter. All it means is
 that the client will abandon the proxy connection for a better one with
 less 

Re: [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_revision
 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_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 dcf):

 Replying to [comment:27 cohosh]:
 > - We don't currently have unit tests that check the client and server
 integration and we should have them

 I ported my recent
 [https://github.com/net4people/bbs/issues/14#issuecomment-542898991 Turbo
 Tunnel prototype program] to `SnowflakeConn`. You'll have to check it; I
 may have gotten the API wrong. But perhaps it can help test in a
 controlled environment.

 attachment:reconnecting-snowflakeconn.zip

 I managed to get a few panics, trying different things.

 

 {{{
 server$ ./server 127.0.0.1:4000
 2019/10/17 21:14:11 error in handleConn: EOF
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4f8d24]

 goroutine 5 [running]:
 github.com/cohosh/snowflake/common/snowflake-
 proto.(*SnowflakeConn).Write(0xcba000, 0xc307a8, 0xc, 0x20, 0xc,
 0x20, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:337 +0x424
 main.handleConn.func1(0xcba000)
 reconnecting-snowflakeconn/server/main.go:62 +0x87
 created by main.handleConn
 reconnecting-snowflakeconn/server/main.go:58 +0x207
 }}}

 {{{
 client$ ./client 127.0.0.1:4000
 2019/10/17 21:14:08 begin SnowflakeConn c0bd93336fcab1ef
 2019/10/17 21:14:08 begin TCP connection 127.0.0.1:52386 -> 127.0.0.1:4000
 abcd
 ABCD
 ^C
 client$ ./client 127.0.0.1:4000
 2019/10/17 21:14:15 begin SnowflakeConn e446789c28f69bbc
 2019/10/17 21:14:15 begin TCP connection 127.0.0.1:52388 -> 127.0.0.1:4000
 xyz
 XYZ
 2019/10/17 21:14:19 stdout <- conn finished: EOF
 }}}

 This looks like it's the `err`/`err2` confusion from comment:28.

 

 {{{
 lilbastard$ lilbastard -w 10 127.0.0.1:3000 127.0.0.1:4000
 }}}

 {{{
 $ ./server 127.0.0.1:4000
 2019/10/17 21:18:41 error in handleConn: EOF
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4f8d24]

 goroutine 5 [running]:
 github.com/cohosh/snowflake/common/snowflake-
 proto.(*SnowflakeConn).Write(0xcbe000, 0xc2ffa8, 0xc, 0x20, 0xc,
 0x20, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:337 +0x424
 main.handleConn.func1(0xcbe000)
 reconnecting-snowflakeconn/server/main.go:62 +0x87
 created by main.handleConn
 reconnecting-snowflakeconn/server/main.go:58 +0x207
 }}}

 {{{
 $ ./client 127.0.0.1:3000
 2019/10/17 21:18:31 begin SnowflakeConn f2a5d31f6afa8727
 2019/10/17 21:18:31 begin TCP connection 127.0.0.1:39108 -> 127.0.0.1:3000
 abcd
 ABCD
 efgh
 EFGH
 ijkl2019/10/17 21:18:41 stdout <- conn finished: EOF

 2019/10/17 21:18:51 Closing WebRTC connection, timed out waiting for ACK
 }}}

 This looks similar, except the server and client report an EOF first.

 

 {{{
 server$ ./server 127.0.0.1:4000
 }}}

 {{{
 client$ yes | ./client 127.0.0.1:4000
 2019/10/17 21:16:01 begin SnowflakeConn eb27f73167a77490
 2019/10/17 21:16:01 begin TCP connection 127.0.0.1:52392 -> 127.0.0.1:4000
 2019/10/17 21:16:11 Closing WebRTC connection, timed out waiting for ACK
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4f52c4]

 goroutine 6 [running]:
 github.com/cohosh/snowflake/common/snowflake-
 proto.(*SnowflakeConn).Write(0xca4000, 0xcb8000, 0x8000, 0x8000,
 0x8000, 0x0, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:337 +0x424
 github.com/cohosh/snowflake/common/snowflake-proto.Proxy(0x55edc0,
 0xca4000, 0x55ef80, 0xc0e010, 0x0, 0x0, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:406 +0xf0
 main.run.func1(0xc12380, 0xca4000)
 reconnecting-snowflakeconn/client/main.go:37 +0x7d
 created by main.run
 reconnecting-snowflakeconn/client/main.go:35 +0x3e8
 }}}

 This panic is in the client rather than t

Re: [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 dcf):

 * Attachment "reconnecting-snowflakeconn.zip" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 dcf):

 I think this design is looking pretty good. You and I converged on similar
 decisions here and in
 https://github.com/net4people/bbs/issues/14#issuecomment-542898991, such
 as maintaining a dynamic map of session ID to `net.Conn` on the server,
 and treating a session ID as a `net.Addr`.

 I see that a map of the type
 
[https://github.com/cohosh/snowflake/blob/1707fcc125180b73509688a510bfbe8fa697a99d/server/server.go#L44-L48
 Flurry] maintains the set of mappings from client session IDs to
 (Snowflake proxy, OR conn). The map definitely needs protection against
 concurrent modification—I wonder if that's the cause of the occasional
 server failures you saw. If you haven't done it yet, try building with `go
 build -race` and see whether it reports anything. Take a look at the
 `connMap` type in reconnecting-kcp/server/conn_map.go in
 https://github.com/net4people/bbs/files/3736441/turbo-tunnel-reconnection-
 demo.zip. It's meant to be a synchronized version of the same data
 structure.

 Could `Flurry.conn` be a plain `net.Conn`, and `Flurry.or` also? Or do
 they need the specialization to `*proto.Snowflake.Conn` and
 `*net.TCPConn`?

 Could the directory common/snowflake-proto be called common/proto instead,
 so that the directory name matches the package name?

 > I see some motivation for another feature that allows us to set some
 kind of FIN or RST flag to notify the client that the OR port has been
 closed and the server that the client has closed the connection.

 Yes, but in the Tor model, it essentially never happens that a
 relay/bridge closes an ORPort connection, right? It's usually the client
 that decides when to disconnect.

 > Perhaps 10s is too long a timeout?

 I don't understand this. Do you mean too ''short'' a timeout? As a
 retransmission timer, 10 s doesn't seem short, but as a timer that
 terminates the whole end-to-end connection, it does seem short. Since in
 this design, there's no retransmission except when kicked off by a
 `NewSnowflake` transition, it might be worth increasing the timeout.

 I'm not sure about
 
[https://github.com/cohosh/snowflake/blob/1707fcc125180b73509688a510bfbe8fa697a99d/common
 /snowflake-proto/proto.go#L341-L353 this design] of setting a timer on
 every `Write`, to wait for the ack to come back. Does the `timers` slice
 grow without bound? In the name of simplicity, could there be one timer,
 that gets reset whenever any amount of data is acked?

 Speaking of timeouts, I think it's worth reducing the timeout in tests, to
 make them run faster.

 I don't understand the design where methods such as
 
[https://github.com/cohosh/snowflake/blob/1707fcc125180b73509688a510bfbe8fa697a99d/common
 /snowflake-proto/proto.go#L168 NewSnowflake] and
 
[https://github.com/cohosh/snowflake/blob/1707fcc125180b73509688a510bfbe8fa697a99d/common
 /snowflake-proto/proto.go#L242 readLoop] take an optional
 `*snowflakeHeader`. Can you explain that?

 What's the reason for the
 
[https://github.com/cohosh/snowflake/blob/1707fcc125180b73509688a510bfbe8fa697a99d/common
 /snowflake-proto/proto.go#L76-L78 nil check in snowflakeHeader.Marshal]?
 It's not a typical pattern for a method like this. Is there a place where
 the error is anticipated, or would it always indicate a bug of some sort?

 It looks like
 
[https://github.com/cohosh/snowflake/blob/1707fcc125180b73509688a510bfbe8fa697a99d/common
 /snowflake-proto/proto.go#L333-L339 this block] is meant to return `0,
 err2`, not `len(b), nil`? Also `err2.Error()` in the log statement, not
 `err.Error()`.
 {{{
 if err2 != nil {
 log.Printf("Error writing to connection: %s", err.Error())
 return len(b), nil
 }
 }}}

 `SnowflakeConn` needs a test for duplicate and overlapping sequence
 numbers. That's the primary expected use case: the client sends 100 bytes
 with seq 1234, the server receives, the proxy dies before sending the
 server's ack, the client reconnects to a different proxy and retransmits
 the same 100 bytes with seq 1234, the server receives duplicate sequence
 numbers and should ignore the seco

Re: [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:

 Okay I made a lot of changes, and it's done in the sense that the
 sequencing and reliability layer is fully integrated to the client and
 server and all the features I think we want are there. I've squashed these
 changes into two commits on a new branch:
 https://github.com/cohosh/snowflake/compare/sequencing_squashed

 The first commit adds the new SnowflakeConn network connection and the
 second integrates it into both the client and the server.

 Honestly I think it'll need another round of revisions for the following
 reasons:
 - The locks are a bit messy and I think we'll need more
 - We don't currently have unit tests that check the client and server
 integration and we should have them
 - In my integration tests I'm seeing the server occasionally fail, but I
 haven't figured out how yet

 Right now there's a plain http test deployment of this server running on
 ws://68.183.200.16 if you want to try it out.

 Some additional notes:
 - I see some motivation for another feature that allows us to set some
 kind of FIN or RST flag to notify the client that the OR port has been
 closed and the server that the client has closed the connection. Right now
 each endpoint can't tell the difference between a problem with the
 snowflake proxy and with an endpoint.
 - Even though we aren't closing the OR connection on the server side when
 a snowflake dies, from my tests it looks like the second snowflake
 connection isn't happening fast enough and I'm still getting a `connection
 reset by peer` error when I try to write to it again.

  Perhaps 10s is too long a timeout?

  Is there a client keep-alive functionality that should happen that we can
 simulate at the bridge?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 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):

 Thanks for the feedback! I added a bunch of new commits onto the
 [https://github.com/cohosh/snowflake/compare/sequencing sequencing branch]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 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_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 dcf):

 I would like there to be a paragraph-long or so comment at the top of
 snowflake-proto/proto.go that briefly explains how things work.

 `windowSize = 1500` seems small; it would only allow for ≈1 full-sized
 packet in flight at a time. (I realize `windowSize` is not used yet.)

 Does `SnowflakeConn.Conn` need to be exposed publicly? Maybe
 `NewSnowflakeConn` and `SnowflakeConn.NewSnowflake` should be the only
 ways to modify it externally.

 `LocalAddr`, `RemoteAddr` should return non-nil. They could pass through
 to `s.Conn.LocalAddr` and `s.Conn.RemoteAddr`, but maybe better is to have
 them return an `Addr` type that reflects the `sessionID`, because that is
 our persistent addressing abstraction over ephemeral network connections.
 Like:
 {{{
 type sessionAddr []byte;
 func (addr sessionAddr) Network() string {
 return "session"
 }
 func (addr sessionAddr) String() string {
 return string(addr)
 }
 }}}

 The `header.ack > s.acked` comparison looks like it will have problems
 with overflow. It probably ought to be something like `int32(header.ack -
 s.acked) > 0` instead. Same on the inside, it is probably important to use
 `int32` rather than `int`. There should be a test for it, too.
 {{{
 if header.ack > s.acked {
 // remove newly acknowledged bytes from buffer
 s.buf.Next(int(header.ack - s.acked))
 s.acked = header.ack
 }
 }}}

 You don't need an extra check here because
 [https://golang.org/pkg/io/#Writer io.Writer says] "Write must return a
 non-nil error if it returns n < len(p)."
 {{{
 //TODO: check to make sure we wrote out all of the bytes
 }}}

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

 The `NewSnowflake` function writes the locally buffered bytes directly to
 the underlying `Conn`, without prepending new headers as
 `SnowflakeConn.Write` does. I expected it to chop up the buffer into new
 packets and send them with headers (and up-to-date ack numbers).

 `io.ReadFull(r, b)` would be more clear than `io.ReadAtLeast(r, b,
 len(b))`.
 {{{
 b := make([]byte, snowflakeHeaderLen, snowflakeHeaderLen)
 _, err := io.ReadAtLeast(r, b, snowflakeHeaderLen)
 }}}

 I don't think this is worth checking for in `SnowflakeConn.Read`. I would
 just let it crash. Or else, panic instead of returning an error. In any
 case, a check on `s.Conn` would be better in `readLoop` than `Read`,
 because `Read` does not even access `s.Conn`. A better overall design may
 be to have `NewSnowflakeConn` take a `Conn` as a parameter, so that it's
 impossible to create one that's uninitialized.
 {{{
 if s.Conn == nil {
 return 0, fmt.Errorf("No network connection to read from
 ")
 }
 }}}

 Replying to [comment:23 cohosh]:
 > 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 th

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 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):

 Updating this for those following along at home.
 [https://github.com/cohosh/snowflake/compare/sequencing branch]

 Recent changes:
 - added a sessionID
 - rewrote the snowflake tests to use `net.Pipe`
 - added a timeout feature to close the underlying connection if sent data
 was not acknowledged

 Next steps:
 - send acknoweldgements
 - correlate the sessionID on both ends

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 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 gaba):

 * keywords:  ex-sponsor-19, anti-censorship-roadmap => anti-censorship-
 roadmap-september


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-

Comment (by dcf):

 I'm thinking one other field that will be required is some kind of session
 ID, to enable the server to associate connections that come in via
 different proxies. meek has something like this, to link up separate HTTP
 requests:
  * https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-
 server/meek-server.go?h=0.33#n147
  * [[doc/AChildsGardenOfPluggableTransports#meektransportlayer]]
 QUIC uses a Connection ID that is just a random string generated by the
 initiator.
  * https://quicwg.org/base-drafts/draft-ietf-quic-
 invariants.html#rfc.section.4.3
  * https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-5.2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-

Comment (by cohosh):

 Replying to [comment:17 dcf]:
 > Replying to [comment:13 cohosh]:
 > > I'm going to ask for an incremental review on this one, mostly just to
 get another pair of eyes on what I've done and my next steps before I sink
 more time into going possibly the wrong direction:
 https://github.com/cohosh/snowflake/compare/sequencing
 >
 Thanks for the feedback! I've addressed most of the feedback so far here:
 https://github.com/cohosh/snowflake/tree/sequencing
 > The fields would be better as `uint32`, because the size of `int`
 [https://golang.org/ref/spec#Numeric_types may vary] (though I think you
 handled it correctly by always specifying 32 bits in serialization
 functions). `length` may be better as `uint16`; that's plenty for one call
 to `Write` and it avoids the risk that an implementation will try to
 buffer 4 GB in memory.
 Fixed in
 
[https://github.com/cohosh/snowflake/commit/c102894bb903857061e7705e9525612eb9a99b4b
 c102894]
 >
 > IMO `length` should be ''exclusive'' of the header size. Otherwise you
 have to define what it means if `length` < 12. (I believe the current code
 doesn't work in this case because `header.length - snowflakeHeaderLen`
 underflows.) The packets sent by `sendAck` should have `length` = 0.
 >
 Fixed in
 
[https://github.com/cohosh/snowflake/commit/02bfa1b4611db39a99379eefd29d569563490a0a
 02bfa1b]
 > Big-endian is more usual for network protocols.
 >
 Fixed in
 
[https://github.com/cohosh/snowflake/commit/7566cbc9e3d289a901d717e2ed5bc10a335915d7
 7566cb]
 > I'm not sure about the implementation of `Read`:
 > I would prefer to start with an implementation of `Read` that is
 simpler, if less efficient. I am picturing something like this [...]
 I like this implementation a lot more. Fixed in
 
[https://github.com/cohosh/snowflake/commit/b6fb987ba9aca02c6740231df6c9db60b68993a6
 b6fb987] and
 
[https://github.com/cohosh/snowflake/commit/9c1b12f7c645e0a8a95199190d89b84ed677e3f8
 9c1b12f]

 I'm going to start on implementing fixed size send windows and cleaning up
 the unit tests a bit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake (was: New design for client -- proxy protocol for Snowflake)

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by cohosh):

 * status:  needs_review => needs_revision


Old description:

> Right now we just send traffic. We need to add some control messages for
> communication between the client and proxy.

New description:

 Right now we just send traffic. We could add some control messages or
 another layer for reliability/sequencing.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs