[tor-dev] IRC meeting to discuss sponsor F progress on Tue September 3, 18:00 to 19:00 UTC in #tor-dev

Karsten Loesing karsten at torproject.org
Wed Sep 4 16:27:58 UTC 2013

On 8/30/13 8:00 AM, Karsten Loesing wrote:
> Hi all,
> I'd like to schedule an IRC meeting to discuss what progress we made on
> sponsor F deliverables in August.  Time and place are:
>   Tue September 3, 18:00 to 19:00 UTC in #tor-dev

Below are my notes from our discussion in #tor-dev yesterday.

I usually report progress from the past month to Andrew, so that he can
write a monthly report.  And I usually add plans for the current month
to my task organizer tool, so that I can ask people for progress.  But
Tom indicated interest in reading these notes.  I figured I can as well
send them to the list.

Note that this mail is a can-read for developers, not at all a


#2 Enable IPv6-only clients to bootstrap

- No progress to report.

- Nick is going to do #6027 ("Directory authorities on IPv6") if he can.

#3 Make Shadow/ExperimenTor/Deterlab more accurate

- No progress to report.

- Karsten is going to get #7359 ("Design/implement method for
collecting/reporting statistics") ready to be merged.

#5 Make progress on proposal 195

- No progress to report.

- Nick is planning to review his own patch to #7145 ("Evaluate, possibly
revise, and then implement ideas for TLS certificate normalization"),
because Roger and Andrea are already hosed.

#8 Make Torperf results more realistic

- No progress to report.

- Karsten is going to write a short design document summarizing his
ideas on a Torperf Twisted rewrite.  He's going to send this document to
tor-dev@, ideally before September 10.
- Sathya is going to implement what's specified in the design document.

#10 Make UDP transport work

- Karsten fixed Steven's utp branch and got it working both in a
client/private bridge setup in the public Tor network and in a small
private Tor network created with Chutney.

- Karsten still has issues simulating his utp branch in Shadow which
he's going to discuss with Rob and hopefully resolve together in September.
- We achieved all must-do items of this deliverable and have some
should-do items left, including the simulations mentioned before.
Implementing or evaluating alternative approaches won't be part of year
3 anymore.  Suggesting next steps will be part of preparing year 4.
Quite a few people on #tor-dev would have input on a new deliverable there.
- It might be useful to write a short tech report containing simulation
results, so that we can reference results when making new plans.  This
tech report won't suggest sensible next research/development steps and
likely outcomes, but will only contain experiment results.  This step is
optional.  Putting a PDF with graphs on Trac and commenting on it would
also be sufficient.

#11 Combine traffic obfuscation and address diversity

- David, Ximin, and George have a working prototype of
obfs3-over-websocket.  This prototype needs more work, because one has
to start up a flash proxy manually, and because the code generally needs
more cleaning up before being deployed.

- George is planning to do #9349 ("flashproxy facilitator: Allow clients
to specify transports") by September 15, and if he can't do it on time,
Ximin is going to step in.  This is the facilitator part of #7167
("Combine traffic obfuscation with address diversity of flash proxy"),
so to say.
- Ximin and George are optimistic that they're on track with this
deliverable and that it should result in something quite robust and
polished by end of October.

#12 Get user statistics for obfsproxy bridges

- Nick and George worked together on merging #4773 and #5040 into tor
master.  George asked obfsbridge operators to upgrade to tor master.
There were four bridges running this code on August 31, though some of
them were not configured correctly.

- George updated his instructions for obfsbridge operators to run tor
master and report by-transport statistics on September 4.  The step that
was missing is that they also need to open their ExtORPort as described
in #9627 ("Document ExtORPort in tor manual page").
- Roger and Nick plan to release tor in September which
will contain the necessary code for bridges to report by-transport
- George is going to ask people running bridges that are hard-coded in
the PT TBBs to upgrade to either tor master or once it's
there and open their ExtORPort.
- Lunar suggests upgrading Tor Cloud images to contain either tor master
or once it's there.  Runa would probably do this, though
she doesn't know about this plan yet.

#13 Make N23 work

- Charlie Belmer rebased Roger's n23-5 branch to master and started
simulating it using Shadow.  He ran into issues there and doesn't have
useful simulation results yet.

- Karsten is going to help Charlie locate issues with simulating his
branch, either by increasing logging and finding the problem in the
logs, or by running it in Chutney.

#14 Evaluate alternate scheduling algorithms

- Andrea made progress on a big refactoring and pushed a non-finished

- Nick is going to review Andrea's non-finished patch when he can to
give her some useful feedback.
- Karsten is going to ask Andrea for an update when she's back around
September 15.

#15 Investigate minimum relay bandwidth

- No progress to report.

- Karsten is going to follow up with Aaron Johnson about getting
simulation results from the experiment that Roger suggested which could
help answer diversity implications of raising requirements for getting
the Fast flag.

#16 Make push-to-talk VoIP work

- Unclear.  Asked Nathan in private mail on September 4.

- No plans known yet.

#17 Make existing VoIP client work

- Matt and Colin wrote a guide for the wiki:
The main issue is that the proxy settings leak DNS, and torsocks doesn't
work on Windows, so there is no solution for Windows at the moment.

- Roger suggests investigating torcap or tortilla for making Mumble work
over Tor on Windows.  Colin tentatively offered to take a look.
- Matt opened an issue on Mumble's bug tracker about leaking DNS, and
someone grabbed it.  Roger suggests writing and submitting a patch, but
Matt admits that this may be beyond his capabilities.  Maybe following
up on this bug with Mumble people could get this issue fixed.
- Once the Tor network is not overloaded anymore, which will hopefully
be the case in October, Matt and Colin are going to write a blog post
with their instructions and get more people to try them out.  Postponing
until October.

#18 Improve options for private Tor networks

- Unclear.  Asked Linus in private mail on September 4.

- No plans.

#19 Fix public-relay-as-bridge bug

- Roger received some feedback to his tor-talk@ posting from July, but
he says most people didn't understand that they had to leave their tor
running while testing.  Roger is unconvinced that this bug has been
tested much.

- Roger suggests not doing anything here in September, in favor of our
other September work.

#20 Prototype integration of Defiance’s client-side components

- No progress to report.

- No plans.

#21 Evaluate plan for Apache in front of Defiance Tor component

- No progress to report.

- No plans.

#22 Evaluate classifiers for throttling clients

- No progress to report.

- Karsten is going to badger bandwidth authority operators to move the
bandwidth authority tors to be relays, so they won't get throttled.
This is #9369 ("Move the bwauths to be relays, so they won't get
- Once #9369 is done Roger thinks we can turn #9368 on ("Turn static
throttling on in the live network").
- Roger mentions that doing #9368 won't fully resolve this deliverable.
 He should write up his idea for more responsive throttling, too.
Postponed until October.

More information about the tor-dev mailing list