Re: [tor-bugs] #6414 [Ooni]: Automating Bridge Reachability Testing

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#6414: Automating Bridge Reachability Testing
--------------------------------------------------------------------------------+
 Reporter:  isis                                                                |          Owner:  isis    
     Type:  project                                                             |         Status:  accepted
 Priority:  normal                                                              |      Milestone:          
Component:  Ooni                                                                |        Version:          
 Keywords:  bridge-reachability metrics-db automation testing SponsorF20121101  |         Parent:          
   Points:                                                                      |   Actualpoints:          
--------------------------------------------------------------------------------+

Comment(by asn):

 Replying to [comment:9 isis]:
 > Replying to [comment:4 aagbsn]:
 > > Replying to [comment:2 asn]:
 > >
 > > > b) How many bridges should you test each time? Should we test _all_
 bridges, or just a small sample of bridges (with diverse characteristics
 (like country, tor version, etc.))?
 > >
 > > No single measurement point should have a complete view of all the
 bridges.
 > >
 > > How often are bridges being scanned? Hourly? Daily? Weekly? Longer?
 > >
 >
 > For testing the reachability tests, I was assuming that we'd set up our
 own bridges. In addition to not risking burning volunteer's bridges, we'd
 also have a more controlled setting for getting better data about what's
 safe to do from a given country and what isn't (at least for the present).
 >
 > And, for the general case, once the tests are established, I don't think
 unwarranted scanning should be done very often, perhaps once per week or
 likely even less. By unwarranted, I mean, "we're not noticing a drastic
 drop in connections to bridges from this country, but we're going to scan
 from there anyway just as a check."
 >
 > Also, in the case of unwarranted scanning, I would guess that scanning
 about 5 bridges would suffice, but I do not know the statistical
 percentage of them likely to be duds to begin with. Do either of you have
 any opinions on what would be a good number to scan, that would give us
 accurate results, but also be as small and risk averse as possible?
 >

 I think I would approach this problem by finding some bridge properties
 that are interesting from a reachability PoV (tor version, country,
 uptime, etc.) and then I would try to compile a diverse list of bridges
 wrt those properties.

 Finding the right properties and the right amount of bridges will probably
 require some tweaking and real life testing.

 > > >
 > > > c) How much do we care about burning a bridge during reachability
 testing?
 > >
 > > What scenarios do you think could cause a bridge to get burned in a
 way that would not also apply to every other bridge being scanned as well?
 > >
 >
 > I'm not sure if I understand this question? Could you please explain
 more?
 >

 Oops, sorry for the confusion. I wanted to ask: how much do we care if a
 bridge gets blocked during reachability testing? That is, how much do we
 value our bridges?

 I think that answering this question will help us tackle many other
 questions (including "how many bridges should we test each time?" and
 "which tests should we run for each bridge?").

 I suspect that the answer to this question is variable and depends on many
 factors (like, how many unblocked bridges we have in total, where the
 bridge is located, how fast it is, how much usage it sees, etc.).

 > > >
 > > > f) What about reachability testing on bridges that support pluggable
 transports?
 > >
 > > This is also a necessary component for the Bridge Authority -- bridges
 (0.2.4) can spam whatever transport lines they please, and BridgeDB eats
 it up and advertises it. For every pluggable transport type, there ought
 to be a corresponding reachability test.
 >
 > I was wondering about this and forgot to add it as a question. Is there
 any way to test that an Obfs2 bridge is actually running without compiling
 Obfsproxy and controlling an Obfs2-configured Tor client?
 >

 You can't be 100% sure without running an obfs2-configured Tor client.

 I mean, you can run cheap tests like TCP port scans, or checking the
 entropy of the data returned by the server, but you will never be sure
 that it's obfs2 without speaking the Tor protocol with the bridge.

 This pretty-much comes down to #6396.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6414#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs