Hi guys,<br>This is the initial proposal for "Integrating Tor with user-space transport protocol<br>libraries" during GSOC 2012. <br><br>Proposal:<br>After initial shortlisting of transport protocols to be integrated with tor, I<br>
am left with sctp and udp. Initially I was willing to go with sctp but after<br>getting suggestions on irc, I propose to integrate the udp library for datagram<br>transport to tor (modified tor) as my gsoc 2012 project.  I am leaving sctp (for<br>
now) and choosing UDP because: 1) I learn that testing has been done for libutp<br>(utp) and results seem good. so risk of failure is minimized.  2) The libutp has<br>faced the test of time and seen wide usage (u-torrent) 3) The library is already<br>
available. Although modifications will need to be done to make it work with<br>tor.. So work from very beginning need not be done. Other stacks are also<br>available. But It seems to be closest to what we need(based on what I know so<br>
far. Also Ref: Mentioned in the paper too: Comparison of Tor Datagram Designs.)<br>4) The sctp kernel space implementation has been heavily tested (as told by<br>jmurdoch) but because of security issues mentioned in the paper of its use, sctp<br>
does not seem to be first choice to bet upon.<br><br>Based on Datagram Testing Plan paper,march,2012, I would most likely fit to work<br>on utp and hop-by-hop transport beginning in may. (I'd have no other commitment<br>
by that time.) Circuits are constructed preemptively using tcp in tor.<br><br>Also since different transports are to be tested in future (possibly), So<br>changes to be done in the tor should help it by providing a clean interface to<br>
change the protocol  (sort of plugin interface.. Although the protocols are<br>already layered to accomplish it, but reusability factor need to be taken care<br>of as much as possible)<br><br>As the hop by hop reliability is easier to implement (less changes to tor) and<br>
project of new transport protocol is new to tor, so not much experience is<br>available. Thus as an experiment, the hop by hop reliablity seems to be the best<br>selection right now (obviously with the scope of making changes in future)<br>
<br>Also if the modified tor is tested on the live tor network, hop by hop<br>reliability'll help in addressing the issue of deanonymization of nodes because<br>major population of nodes'll be using tcp during the migration period.  As<br>
mentioned in "Improving Tor using a TCP over DTLS" paper by Reardon, the<br>implementation of DTLS (TLS for Datagram) is already there in OpenSSL. TLS and<br>DTLS apis are unified too, i.e. same OpenSSL calls'll be able to handle sending<br>
and receiving data with minimum changes which'll have to be made to tor.<br><br>I'd be extremely careful about the overall implementation so that changes done<br>in tor don't just emerge out as a separate new branch and act as blockage for<br>
other transports and future changes. Instead, changes should be made to<br>complement the future development.<br><br>Goals to keep in mind for taking decisions while implementing:<br>To achieve Low latency and scalability are two goals that I see to keep in mind<br>
while implementing/integrating the protocol to tor. Thorough testing is only<br>viable option for ensuring these though. But as mentioned in the Datagram<br>Testing Plan paper, simulation is also fine..(Please make additions here) In the<br>
end, As integrating new transport is not an individual's task to complete, its<br>being done by a team and a plan is already there (Murdoch's march paper). So<br>this proposal is for me to be of value to the team and not be limited to the<br>
libutp.  So if time permits, I intend to help by contributing to other parts of<br>this project too especially Experimentor.<br><br>By the way, where can I find the md5 or sha digests for the Experimentor?<br><br>Timeline:<br>
Google summer of code 2012 will be a 12 week (3 months) programme: I would like<br>to report my progress twice each week preferably wednesday night (utc+0) and<br>saturday night (again utc+0). I will submit the detailed timeline after making<br>
the proposal almost final.. I've planned to maintain a blog or github pages  to<br>provide the details about the project's progress..I would be available on irc<br>for all of my working time though.<br>Currently github repository for my torprojectgsoc12:<br>
<a href="https://github.com/drake01/torprojectgsoc2012">https://github.com/drake01/torprojectgsoc2012</a> (its empty, I'll  fill it soon:) )<br><br>Test code:<br>I am planning to submit a socket based small server/client app through above<br>
repository which I wrote in initial days while learning( needs some changes to<br>distribute though).. Also would try to write something utilising raw sockets to<br>show my understanding of Internet Protocol stack. Comments!<br>
<br>Current status:<br>I have cloned the git repository of tor and a few related softwares including<br>libutp and have it working on my machine. Also started to dissect the libutp<br>code.<br>I have gone through the papers, Comparison of Tor Datagram Designs and<br>
Datagram Testing Plan by Murdoch.<br>I have overviewed the tor-design paper by Nickand Roger.  <br>Github account: <a href="https://github.com/drake01">https://github.com/drake01</a><br><br><br>#vim-7.3<br><br>Comments, Criticism, suggestions are most welcome.. :)<br>
<br clear="all"><br>-- <br>Online pseudonym: drake01, drakeo1 or drakeoone<br>Blog: <a href="http://goo.gl/uMnRp" target="_blank">http://goo.gl/uMnRp</a><br>Github: <a href="https://github.com/drake01" target="_blank">https://github.com/drake01</a><br>
<br>