Sorry, TCP over TCP is believed not a good idea in terms of performance.
On Sun, Feb 26, 2012 at 1:30 PM, Xinwen Fu <xinwe...@gmail.com> wrote: > Hi Chris, > > On Sun, Feb 26, 2012 at 12:09 PM, Chris Wheeler <grin...@gmail.com> wrote: > >> Dr Fu, >> >> About the paper you sent, particularly the section on the simulation >> using continuous-time mix, by the looks of it much of your degradation >> came >> from packets arriving in the wrong order. I know the TCP doesn't handle >> this well natively but what if a wrapper was written? The TCP stream would >> travel inside of our wrapper (which would of course itself would be >> running >> on TCP across the internet - It would mean transporting a TCP stream over >> layer 7 of the OSI model, I think this is how PPTP works) The inner TCP >> stream would be mixed, and the packets out of order but the tor client, >> before forwarding them on to their destination (a hidden service or, if we >> are talking about an exit node, the internet) would rearrange them then >> send them on. >> >> > > Are you going to do the reordering link-by-link or end-to-end? TCP over > TCP is believed a good idea in terms of performance. Also what is the > benefit for privacy enhancing if the client itself reorders everything > back? What is the performance overhead? > > Tor is, I believe, a result after considering many possible options, > including mixes. It evolves from mixes. Mixes use buffer and shuffling in > various ways. > > > >> Another approach to stop correlation attacks might just be to constantly >> send packets at set time intervals, regardless of if you have any data >> to forward. Just pad it with zeros if you have nothing to forward and let >> it get dropped by the client on the other side of the network and of >> course >> send real data when you have something to send. For example have a 5Kb >> buffer, receive packets and place them in that buffer, send the buffer out >> once per ms, if the buffer is not full pad it with zeros, if you have more >> than 5Kb to send cache it for the next ms buffer. >> >> > Traffic padding is also an old topic. Tor has an option of using padding. > I actually did a lot of study on this. The major trouble is the overhead. > Another question is how you set the overall rate of the padded traffic? You > can refer to early papers on padding by my group and Matthew Wright at UT > Arlington. > > Cheers, > > Xinwen Fu > > > >> What do you think? >> Chris >> >> On Sat, Feb 25, 2012 at 9:49 PM, Xinwen Fu <xinwe...@gmail.com> wrote: >> >> > Here is a paper of mine on TCP Performance in Flow-Based Mix Networks: >> > http://www.cs.uml.edu/~xinwenfu/paper/MixPerf_Fu.pdf. >> > >> > If you are interested in why Tor performance is still not super, you an >> > refer to http://www.cs.uml.edu/~xinwenfu/paper/IPDPS08_Fu.pdf. >> > >> > There are many other brilliant works on the performance problem. >> > >> > Cheers, >> > >> > Xinwen Fu >> > >> > >> > On Sat, Feb 25, 2012 at 9:31 PM, Xinwen Fu <xinwe...@gmail.com> wrote: >> > >> > > That is a lot of thinking. Many of the problems have been discussed >> > > before. If you look at the bibliography on mixes, there are a lot of >> > > discussions. Here is one of my papers on mixes: >> > > http://www.cs.uml.edu/~xinwenfu/paper/fu_icdcs05.pdf. An adversary >> may >> > > choose different ways for correlation and attacks. >> > > >> > > What Tor achieves is phenomenal. It works against many attacks. Tor >> > > performance has been improving. I'm saying this because a workable >> system >> > > is not easy. For example, changing packet orders may not be a good >> idea. >> > It >> > > may not help much on security, but will deteriorate the TCP >> performance >> > Tor >> > > relies on. TCP is very sensitive to packet ordering errors. >> > > >> > > Indeed, there are still a lot of things we don't know for sure. >> However, >> > > at least Tor is over there and you can test it on the real one or a >> > private >> > > Tor. >> > > >> > > Cheers, >> > > >> > > Xinwen Fu >> > > >> > > >> > > >> > > >> > > >> > > On Sat, Feb 25, 2012 at 3:49 PM, Joe Btfsplk <joebtfs...@gmx.com> >> wrote: >> > > >> > >> On 2/25/2012 12:41 PM, Xinwen Fu wrote: >> > >> >> > >>> Chris, >> > >>> >> > >>> An attack may only work under its own threat model (capabilities and >> > >>> resources an adversary has). If entries and exit are all secure, >> some >> > >>> correlation attacks may not work. However, if the adversary can >> still >> > >>> observe (not need to compromise Tor routers) the traffic into and >> out >> > of >> > >>> entries and exits, some attacks may still work, e.g., by correlating >> > the >> > >>> traffic patterns at the two sides of a circuit. Here is a paper >> > >>> describing >> > >>> such possibility: >> > >>> http://www.cs.uml.edu/~**xinwenfu/paper/TorCellSize_**ICC11_Fu.pdf< >> > http://www.cs.uml.edu/%7Exinwenfu/paper/TorCellSize_ICC11_Fu.pdf> >> > >>> . >> > >>> >> > >>> Hope it helps a bit. >> > >>> >> > >>> Xinwen Fu >> > >>> >> > >> Thanks for the link, Xinwen. I have a more basic question regarding >> the >> > >> original question of adversaries somehow getting access to BOTH >> entry & >> > >> exit nodes, that lots of users probably are curious about. Re: >> getting >> > >> enough data (even if they could break encryption, if using * SSL *) >> to >> > do >> > >> any good. Since Tor / Vidalia changes nodes often (is it at least >> > every 10 >> > >> min, at most? - & more often if a circuit fails), could an adversary >> get >> > >> enough data about ONE user to do any good? >> > >> >> > >> In this case, is the threat that the adversary will ONLY be able to >> > >> identify that one is USING Tor network (not capture the actual data >> > >> transferred), assuming they have access to the * originating IP >> > address,* >> > >> going to the entry node AND also to the exit node? I suppose (for >> now), >> > >> adversaries in repressive countries determining that one is USING Tor >> > is a >> > >> big problem. Not so much in "free" societies, but that could change. >> > >> >> > >> What effect, if any, would Tor changing relays more frequently than >> the >> > >> current default time, have on ability of adversaries tracking users >> (in >> > a >> > >> meaningful manner) from entry to exit nodes? >> > >> >> > >> In Tor network, does the data packet size & order, in & out of entry >> or >> > >> exit nodes necessarily HAVE to be the same? Would it be possible to >> > make >> > >> the in & out packet sizes different sizes, or mix the order of >> packets >> > at >> > >> an exit vs entry node? (I don't know the technicality of how this >> would >> > >> work). If you d/l a torrent (as an example), you don't receive the >> file >> > >> pieces in order. Is it theoretically possible the Tor network could >> > >> develop a way to mix up the packets (of a file), within the network, >> so >> > >> that even if an adversary had complete access to a given entry & exit >> > >> node(s), the data going in one end could never be matched w/ data >> coming >> > >> out? (don't answer too quickly! Never say never) >> > >> >> > >> This is also somewhat similar in concept to the old data correction >> > >> process, where pieces of a file might be re transferred (due to >> > >> corruption), much later in the d/l process, after most of the file >> was >> > >> already downloaded. >> > >> >> > >> The theoretical concept I'm pondering is, could all pieces of data >> > >> transmission through Tor be scrambled (the order and / or size) on >> > purpose? >> > >> Adversaries generally can't read the actual data because of >> encryption >> > (if >> > >> I understand). If there was also no correlation of packets (to an >> > outside >> > >> observer) at one end vs the other, how could they ever track a user >> by >> > >> traffic analysis? Adversaries would theoretically have to monitor >> ALL >> > >> relays, ALL of the time. >> > >> >> > >> Even then, how would they track a user, end to end, if the packet >> order >> > >> is purposefully & randomly jumbled within the network? It seems that >> > the >> > >> current Tor network model will come under ever increasing attacks / >> > >> monitoring & needs to change the fundamental way it operates. >> > >> >> > >> To some avg users, it might seem there is no way around a determined >> > >> adversary determining they are using Tor (with current Tor network >> > >> technology). >> > >> If an ISP sets up an entry relay or bridge & exit relay, you could be >> > >> screwed. >> > >> If a user goes through a proxy to Tor, and an adversary runs the >> proxy >> > >> (how do we really know?), you could be screwed. >> > >> >> > >> I could go on & on w/ scenarios. Lots of people throw around the >> > phrase, >> > >> "Users have to determine their threat model..." Quite honestly, most >> > >> people wouldn't know how. For avg users, advanced users may as well >> > say, >> > >> "We have no idea. You're own your own. Don't assume you'll be >> > anonymous, >> > >> even if you follow directions exactly for using Tor / TBB." >> > >> >> > >> OK, so instead of everyone shooting down my ideas, modify them so >> they >> > >> might work, or come up w/ other better ideas, instead of continuing >> to >> > put >> > >> band aids on the current technology that seems to be fraught w/ >> > problems. >> > >> >> > >> ______________________________**_________________ >> > >> tor-talk mailing list >> > >> tor-talk@lists.torproject.org >> > >> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk< >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk> >> > >> >> > > >> > > >> > _______________________________________________ >> > tor-talk mailing list >> > tor-talk@lists.torproject.org >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> > >> _______________________________________________ >> tor-talk mailing list >> tor-talk@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> > > _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
