On Saturday 13 December 2008, Karsten Loesing wrote: > Hi Bernhard, > > Bernhard Fischer wrote: > > Sorry, I didn't see this before. I'll read your paper and I appreciate > > all improvements regarding hidden services. > > You might also want to read the documents that are linked from the NLnet > project page, for example: > > http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf Thanks, I had a look at it. Your measurements regarding message transfer reflect pretty much the observations I did. > > While TOR is building circuits there's always some kind of randomness > > involved. As far as I know TOR chooses nodes based on directory flags > > (like "fast", "stable", ...) and the randomizes those matching some > > criteria. Obviously the flag "fast" is somehow misleading because > > bandwidth is a local property and does not necessarily mean that it's > > also fast across the network to any other node. > > Okay, we didn't change anything about path selection so far. One reason > is that this might have serious consequences on anonymity. While it > would be great to make Tor and hidden services faster by using only the > best nodes available, this largely destroys anonymity. All changes here > should be made with extra caution! Of course, you are right. Changes in the path selection algorithm should be done with caution. But it was just an idea which looked feasible for me from a user perspective (SOCKS interface) without changing TOR, thus not risking loss of anonymity. > > I did some RTT measurements and my observations are really ugly. It > > usually is never below 5s. What you can observe is that when the circuit > > is rotated the RTT also changes signifficant. > > See the measurements in the analysis linked above. This document > contains some data about message transfer times after connections are > established. Basically, we excluded message transfer times from the > project, because they didn't seem to be a problem of hidden services, > but rather of Tor in general. That could also be possible. I didn't scientifically proven measurements yet, but I will do. Maybe it's a problem of TOR *and* hidden services. > Another solution is to start performing QoS for hidden services. In > combination with client authorization (see proposal 121), hidden servers > could decide whether to pick an extra-fast circuit to connect to the > client's rendezvous point, or not. > > Having said that, did you look at proposal 121 for OnionCat. I could > imagine that OnionCat would make good use of the additional security > that client authorization offers for hidden services. See also a > Technical Report on that topic: > > http://petsymposium.org/2008/hotpets/vrtprsvc.pdf QoS sounds good but I think it might have same troubles in its deployment as it has in plain Internet. QoS was foreseen in IP since decades but never used network-wide. Until today QoS is always a local service limited to the network of a provider or company. I can imagine that QoS deployment will last very long until it works TOR-network-wide for similar reasons. Regarding authorization: Thanks, I already knew proposal 121 before and I did test those authorizations features. They work and seem to be very useful for some scenarios. Best Regards, Bernhard
Attachment:
signature.asc
Description: This is a digitally signed message part.