Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#4562 closed project (implemented)

Write a pluggable transport deployment roadmap

Reported by: karsten Owned by: asn
Priority: Medium Milestone:
Component: Circumvention/Pluggable transport Version:
Severity: Keywords: SponsorG20120331
Cc: nickm, erinn, chiiph, aagbsn, ioerror Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This ticket is about coming up with a plan for making pluggable transports work in practice, including how to solve the packaging and updating problems. The output document will describe ways for rolling out new protocols in the future, even though the initial deployment will only contain obfs2 as transport. The document will also cover how BridgeDB will give out transport information to bridge users. Basically, the document will describe what users will have to do to use pluggable transports: download a special bundle, learn bridges that support one or more pluggable transports, put the Bridge lines into the torrc or Vidalia, done. The document will also describe how Tor uses UPnP to set up port forwarding to the bridge proxy.

This ticket is part of the March 31, 2012 milestone for sponsor G.

Child Tickets

Attachments (5)

roadmap.tex (6.3 KB) - added by asn 7 years ago.
roadmap.pdf (52.3 KB) - added by asn 7 years ago.
0001-Tweak-footnotes-a-bit.patch (7.9 KB) - added by karsten 7 years ago.
0002-Make-some-minor-changes.patch (3.6 KB) - added by karsten 7 years ago.
roadmap.2.pdf (68.6 KB) - added by asn 7 years ago.

Download all attachments as: .zip

Change History (18)

Changed 7 years ago by asn

Attachment: roadmap.tex added

Changed 7 years ago by asn

Attachment: roadmap.pdf added

comment:1 Changed 7 years ago by asn

I attached an initial draft version of the deployment roadmap document.

comment:2 Changed 7 years ago by rransom

Status: newneeds_revision

The obfsproxy bundle contained 14 obfsproxy bridge addresses, not 25.

comment:3 Changed 7 years ago by Sebastian

Maybe it's 25 together with the orbot thing?

comment:4 Changed 7 years ago by karsten

Cc: erinn chiiph aagbsn ioerror added

Some comments:

  • The document doesn't have an author name nor contact information. Please consider putting in your name and email address.
  • Should Section 2 have its own subsection for saying what changes are required to Vidalia, maybe as new first subsection? If these changes are already made, great, but I think they should be stated in this roadmap. Speaking of Vidalia, are there plans to configure obfsproxy on the server side?
  • In Section 2.1, how will BridgeDB distribute obfuscated bridge addresses? Will users specifically ask for them instead of non-obfuscated bridge addresses, or will BridgeDB include an obfuscated bridge address or two in every response? If there are different transports, will BridgeDB tell you one address per transport, or will the user have to ask for a specific transport? I'm sure there are even smarter questions about possible BridgeDB designs, but I think they should be discussed in Section 2.1 or on Trac and referenced here.
  • Maybe add a remark that statistics mentioned in Section 2.2 won't be deployed on a 0.2.3.x timeframe.
  • Sections 2.2 and 2.4 talk about a future that is farther away than 2.1 and 2.3. Would it make sense to have Section 2 talk about the future in 3--6 months and a new Section 3 talk about the future after that? If not, feel free to ignore this suggestion.
  • In Section 3 you talk about updating obfsproxy on the server side. Are there any plans to have an Obfsproxy Bridge Bundle of some sort? Or will the Tor Bridge Bundle contain obfsproxy by default?
  • In the short-term future as sketched in Section 4, you say that users will download the Obfsproxy Browser Bundle and put in addresses obtained from BridgeDB. Will the bundle still contain any hard-coded addresses by then?
  • Instead of hacking the bibliography with custom \bibitem, please consider using footnotes for URLs.

We should also get feedback from the people who're actually affected by the planned changes. erinn, chiiph, aagbsn, and ioerror come to mind. Adding them to Cc. What do they think?

comment:5 Changed 7 years ago by Sebastian

All in all looks good with karsten's comments. I do think expected timeframe should be mentioned for each subsection, or do we stay vague on purpose?

About deployment, didn't we talk about including obfsproxy in TBB by default in the near (tor 0.2.3.x-stable) future? Maybe that should be mentioned. This would, if we did it, require the Vidalia support karsten mentioned.

There's still a bunch of grammar/spelling errors. Is this expected because it's a rough draft or do you want a patch to fix some?

comment:6 in reply to:  5 Changed 7 years ago by karsten

Replying to Sebastian:

I do think expected timeframe should be mentioned for each subsection, or do we stay vague on purpose?

Good idea. No need to stay vague, at least not with respect to the next sponsor deliverable. We promised UPnP (#4567) and hope to get BridgeDB integration (#4568) done until June 30. We didn't make plans for Vidalia integration until June 30, both client and server side, though I think it would make sense. Anything else is for after June.

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

Thanks for the comments everyone!

I changed the 25 to 14, and made several changes based on Karsten's ideas.
I hope to further improve the English and fix the spelling/grammar mistakes tomorrow or the day after.

I heard that git is good, so I pushed my progress into bug4562 in https://git.gitorious.org/tor-reports/tor-reports.git (https://gitorious.org/tor-reports/tor-reports/commits/bug4562).

Answering to Karsten's review:

Replying to karsten:

Some comments:

  • The document doesn't have an author name nor contact information. Please consider putting in your name and email address.

Done.

  • Should Section 2 have its own subsection for saying what changes are required to Vidalia, maybe as new first subsection? If these changes are already made, great, but I think they should be stated in this roadmap. Speaking of Vidalia, are there plans to configure obfsproxy on the server side?

Good idea. I added a section.

  • In Section 2.1, how will BridgeDB distribute obfuscated bridge addresses? Will users specifically ask for them instead of non-obfuscated bridge addresses, or will BridgeDB include an obfuscated bridge address or two in every response? If there are different transports, will BridgeDB tell you one address per transport, or will the user have to ask for a specific transport? I'm sure there are even smarter questions about possible BridgeDB designs, but I think they should be discussed in Section 2.1 or on Trac and referenced here.

I spoke with Aaron about this. He pretty-much told me that all approaches are quite easy to implement.

He told me that BridgeDB has the concept of each bridge having "characteristics", and that in the near future we will be able to query BridgeDB for specific characteristics.

So, I had in mind that initially we would just give out a couple of obfs2 addresses along with the usual bridge addresses, and then we would progress to a design where the user would be able to query bridgedb for specific transports and whatnot.

Aaron, any comments?

  • Maybe add a remark that statistics mentioned in Section 2.2 won't be deployed on a 0.2.3.x timeframe.
  • Sections 2.2 and 2.4 talk about a future that is farther away than 2.1 and 2.3. Would it make sense to have Section 2 talk about the future in 3--6 months and a new Section 3 talk about the future after that? If not, feel free to ignore this suggestion.

Hm, I'm not sure how to give out timeframes. Is it development timeframe? Or deployment timeframe? I'll have to think a bit about this. I hope to do it tomorrow.

  • In Section 3 you talk about updating obfsproxy on the server side. Are there any plans to have an Obfsproxy Bridge Bundle of some sort? Or will the Tor Bridge Bundle contain obfsproxy by default?

Ha! Very good question. I added a subsection to the User Workflow section for this.

My idea is that in the future (when obfsproxy is mature enough) the Tor Bridge Bundle will contain obfsproxy by default. No one wants to be the operator of a trivially blockable bridge. If you think this is not a good idea, I can remove it from the document.

  • In the short-term future as sketched in Section 4, you say that users will download the Obfsproxy Browser Bundle and put in addresses obtained from BridgeDB. Will the bundle still contain any hard-coded addresses by then?

I left this vague intentionally. I think we should decide as we go along, depending on how censors respond etc.

  • Instead of hacking the bibliography with custom \bibitem, please consider using footnotes for URLs.

Good idea. Done.

We should also get feedback from the people who're actually affected by the planned changes. erinn, chiiph, aagbsn, and ioerror come to mind. Adding them to Cc. What do they think?

comment:8 in reply to:  7 Changed 7 years ago by karsten

Replying to asn:

Replying to karsten:

  • In Section 2.1, how will BridgeDB distribute obfuscated bridge addresses? [...]

So, I had in mind that initially we would just give out a couple of obfs2 addresses along with the usual bridge addresses, and then we would progress to a design where the user would be able to query bridgedb for specific transports and whatnot.

Want to add a sentence about that plan to Section 2.2? Or is that too much detail?

  • Sections 2.2 and 2.4 talk about a future that is farther away than 2.1 and 2.3. Would it make sense to have Section 2 talk about the future in 3--6 months and a new Section 3 talk about the future after that? If not, feel free to ignore this suggestion.

Hm, I'm not sure how to give out timeframes. Is it development timeframe? Or deployment timeframe? I'll have to think a bit about this. I hope to do it tomorrow.

I guess deployment timeframe, given that this is a deployment roadmap. Staying vague is fine, but maybe a hint that statistics in 2.3 will take us longer to deploy than NAT punching in 2.4 might be useful.

  • In Section 3 you talk about updating obfsproxy on the server side. Are there any plans to have an Obfsproxy Bridge Bundle of some sort? Or will the Tor Bridge Bundle contain obfsproxy by default?

Ha! Very good question. I added a subsection to the User Workflow section for this.

My idea is that in the future (when obfsproxy is mature enough) the Tor Bridge Bundle will contain obfsproxy by default. No one wants to be the operator of a trivially blockable bridge. If you think this is not a good idea, I can remove it from the document.

Sounds like a fine idea to me. But I'm in no way involved in building packages, so don't count on my opinion here. Just raising the issue.

  • Instead of hacking the bibliography with custom \bibitem, please consider using footnotes for URLs.

Good idea. Done.

I tweaked the footnotes a bit and made a set of other small changes. See the attached Git patches.

Changed 7 years ago by karsten

Changed 7 years ago by karsten

comment:9 Changed 7 years ago by asn

Thanks for the patches! I applied both, and also added a paragraph on how we plan to incrementally deploy the BridgeDB integration plan.

Why do you think that that statistics in 2.3 will take us longer to deploy than NAT punching in 2.4? Both features will probably go into 0.2.4.x. I care more about client statistics than NAT punching, so I will try to have client statistics ready, faster than the NAT punching code. Specifically, when #4773 gets merged, we will get GeoIP client statistics for free.

Grr! Deployment timeframes are hard to pin down.

comment:10 in reply to:  9 ; Changed 7 years ago by karsten

Replying to asn:

Why do you think that that statistics in 2.3 will take us longer to deploy than NAT punching in 2.4? Both features will probably go into 0.2.4.x. I care more about client statistics than NAT punching, so I will try to have client statistics ready, faster than the NAT punching code. Specifically, when #4773 gets merged, we will get GeoIP client statistics for free.

Ah, I didn't know that you were planning to implement statistics before end of June, which is when we promised the NAT-punching code. And yes, I also think that both features will go into 0.2.4.x.

Very much looking forward to statistics support!

comment:11 in reply to:  10 Changed 7 years ago by asn

Status: needs_revisionneeds_review

I removed the draft warnings, and I'm attaching a final version.

Changed 7 years ago by asn

Attachment: roadmap.2.pdf added

comment:12 Changed 7 years ago by karsten

Resolution: implemented
Status: needs_reviewclosed

Looks good. Thanks! Closing.

comment:13 Changed 7 years ago by karsten

Keywords: SponsorG20120331 added
Milestone: Sponsor G: March 31, 2012

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

Note: See TracTickets for help on using tickets.