[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #15513 [Tor]: Investigate lifetime of IPs on Hidden Services



#15513: Investigate lifetime of IPs on Hidden Services
-----------------------------+--------------------
     Reporter:  donncha      |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-hs
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------

Comment (by karsten):

 Right, the fifth graph didn't show absolute numbers of relays.  I changed
 it and made
 [https://people.torproject.org/~karsten/volatile/lifetimes-2015-04-12.pdf
 updated graphs available].

 Here's a more detailed explanation of these five graphs:

  1. Lifetime of introduction points: This graph shows the number of hours
 between first and last seeing an introduction point in a hidden-service
 descriptor published by one of five publicly known services.  As expected,
 the maximum lifetime of introduction points is 24 hours, with a single
 exception of 25 hours which may be the result of truncating minutes of the
 hour in descriptor publication times.  This graph shows how much lifetime
 of introduction points depends on the service, with agorahoo using almost
 all of its introduction points for at most one hour.

  2. Number of descriptors published per hour, including descriptor
 replicas: The second graph shows how many different descriptors a service
 publishes per hour.  We didn't bother to filter out duplicates from having
 fetched both replicas of a descriptor, which is why most numbers in this
 graph are multiples of two.  This graph shows that four out of five
 services published only two descriptors per hour in 90% of cases, with
 agorahoo publishing at least four in half of cases.  It might even be that
 agorahoo was publishing more descriptors that we didn't fetch.

  3. Number of distinct introduction points used per hour: This graph
 compares all descriptors published by a service in the same hour and
 counts how many distinct introduction points they contain.  Three out of
 five services used only 3 introduction points in 90% of hours, whereas
 kpvz7kpm used at least 5 introduction points in 50% of hours.  agorahoo
 is, again, the exception, with up to 25 different introduction points per
 hour in the extreme case.

  4. Number of introduction points per descriptor: The fourth graph simply
 counts how many introduction points there were contained in a descriptor.
 This number was consistently at 3 for the three services that didn't stand
 out above.  kpvz7kpm did stand out here with using between 4 and 10
 introduction points in half of its descriptors as well as agorahoo with up
 to 10 introduction points in 10% of descriptors.  If additional
 introduction points are established as a result of higher load seen by the
 service, one might say that kpvz7kpm was under higher load half of the
 time whereas agorahoo was under heavy load for only 10% of the time.  It
 would have been trivial to plot these heavy-load times per service at a
 granularity of one hour.

  5. Number of introduction points established on the same relay (in the
 measurement period): This graph shows to what extent relays are being used
 for establishing introduction points.  The agorahoo service serves as best
 example here: while about half of the about 1300 relays have only been
 used a single time for establishing an introduction points, the other half
 was used more than once, up to almost 60 established introduction points
 on a single relay.  This distribution looks plausible, given that tor's
 weighting algorithm favors relays based on their consensus weight.  It's
 more difficult to analyze the other services which have only established a
 tiny number of introduction points in the measurement period compared to
 agorahoo.  On a related note, if services were to change their preferences
 for selecting introduction points, that would stand out very clearly in
 this graph.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15513#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs