Opened 8 years ago

Closed 7 years ago

#4568 closed project (implemented)

Extend BridgeDB to give out pluggable transport information

Reported by: karsten Owned by: aagbsn
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: SponsorG20120930
Cc: nickm, aagbsn, asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We need to teach BridgeDB to give out pluggable transport information in its results. The design will be discussed as part of #4562.

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by asn

Apart from talking with Aaron about this deliverable, I haven't done much wrt its implementation.

A brief implementation plan would be:

  • Extend BridgeDB to parse extra-info descriptors and understand their 'transport' field.
  • Extend BridgeDB to be able to associate transports with bridges.
  • Start giving out pluggable transport information along with the regular bridges in BridgeDB responses (also see roadmap.2.pdf in #4562),

Aaron, do you want to handle this, or should I do it?

comment:2 Changed 7 years ago by aagbsn

I want to do this.

comment:3 Changed 7 years ago by aagbsn

Owner: changed from asn to aagbsn
Status: newaccepted

comment:4 in reply to:  2 ; Changed 7 years ago by asn

Replying to aagbsn:

I want to do this.

Cool! If you need any help, feel free to ask.

comment:5 in reply to:  4 Changed 7 years ago by aagbsn

Cc: asn added

Replying to asn:

Replying to aagbsn:

I want to do this.

Cool! If you need any help, feel free to ask.

Is this the right spec for the extra-info lines:

Advertising bridge methods

  Bridges put the 'method' lines in their extra-info documents.

     method SP <methodname> SP <address:port> [SP arglist] NL

  The address:port are as returned from an SMETHOD line (unless they are
  replaced by the FORWARD: directive).  The arglist is a K=V,... list as
  returned in the ARGS: part of the SMETHOD line's Options component.

  If the SMETHOD line includes a DECLARE: part, the router descriptor gets
  a new line:

     method-info SP <methodname> [SP arglist] NL

from torspec.git/proposal/180-pluggable-transport.txt (93d89226e73cb535088d4cb4104afefdbdfe83c0)

So, should BridgeDB parse the extra-infos directly? If the Bridge Authority does reachability tests for some or all pluggable-transports, how will this be indicated to BridgeDB?

Bridge authority behavior

  We need to specify a way to test different transport methods that
  bridges claim to support.  We should test as many as possible.  We
  should NOT require that we have a way to test every possible
  transport method before we allow its use: the point of this design
  is to remove bottlenecks in transport deployment.

comment:6 Changed 7 years ago by aagbsn

asn and I chatted on IRC, and here's what we discussed:

  • There is no reachability test in the bridge-authority that tests obfs yet (src/or/dirspec.c)
  • Extend the PT (Pluggable Transport) spec to include a reachability-test requirement
  • PT addresses may be different than or-address or the bridge default address.
  • the extra-info descriptor line transport line for obfs3 looks like: "transport obfs3 21.43.65.87:9021"

What we proposed:

  • In the interim (June 15): BridgeDB should read transport lines from extra-info document; if a bridge has the 'running' flag and published pluggable transports then BridgeDB will publish them in its response.
  • In the short term (???): bridge-authority should do reachability testing of PTs, and include the reachable PTs in the networkstatus, similar to ln5's #5534
  • asn will look into reachability test ideas


comment:7 Changed 7 years ago by asn

Aaron, any news on this one?

comment:8 Changed 7 years ago by karsten

I'm interested in news, too. This is still scheduled for June 30, right?

comment:9 Changed 7 years ago by asn

Status: acceptedneeds_review

Aaron has implemented this. I think the results can be found in https://gitweb.torproject.org/user/aagbsn/bridgedb.git/shortlog/refs/heads/4568-add-pluggable-transport .

He has also set up a sample bridgedb with some example transports in a test machine somewhere. Maybe he can post the link so that you can check it out.

comment:10 Changed 7 years ago by karsten

Milestone: Sponsor G: June 30, 2012Sponsor G: September 30, 2012

Moving to the September milestone, because did not finish everything by end of June.

comment:11 Changed 7 years ago by karsten

Keywords: SponsorG20120930 added
Milestone: Sponsor G: September 30, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:12 Changed 7 years ago by aagbsn

Awesome, #3589 is closed. We need to get a few obfsproxy bridges running Tor 0.2.4.x and then we can expose BridgeDB's transport query interface to the world.

The idea is to put together a wiki page and a blog post with some instructions so that interested people can help BridgeDB start handing out obfsproxy bridges.

p.s. the related branches live here:

https://git.torproject.org/user/aagbsn/bridgedb.git

aagbsn/4568-add-pluggable-transport (feature branch) and aagbsn/devel (integration branch, to be merged into master)

comment:13 Changed 7 years ago by karsten

Resolution: implemented
Status: needs_reviewclosed

Looks like BridgeDB now gives out pluggable transport information at https://bridges.torproject.org/?transport=obfs2. Closing. Thanks!

Note: See TracTickets for help on using tickets.