What to do at IP number change?

[Scott Bennett]

     I wrote:
+     On Tue, 08 Jan 2008 22:32:23 -0600 Jon McLachlan <mcla0181 at umn.edu>
+wrote:
+>Scott Bennett wrote:
+>>      On Tue, 08 Jan 2008 14:15:05 -0600 Jon McLachlan <mcla0181 at umn.edu>
+>> wrote:
+>>   
+>>> dr._no at cool.ms wrote:
+>>>     
+>>>> Another point is that without a tor server my home would be vulnerable to traffic 
+>>>> analysis and a further point is that a tor server is more safe than only a client.
+>>>>   
+>>>>       
+>>> I think this depends largely on what type of traffic analysis we're 
+>>> talking about.  Traffic analysis, just looking at traffic, almost always 
+>>> divulges some level of information.  For example, if a local passive 
+>>> adversary simply watched a Tor Relay that was suspected to also contain 
+>>> a Tor Client, then one could imagine a simple traffic analysis as follows:
+>>>
+>>> 1)  Establish running totals of all incoming and outgoing traffic from 
+>>> the machine.
+>>>
+>>> 2)  Then, closely monitory when it is the case that the outgoing traffic 
+>>> level "spikes" or when the incoming traffic level "spikes" as they could 
+>>> indicate that a Tor Client was using the relay as an entry point.  How 
+>>> much it "spikes" could fingerprint a website ... or even be a 
+>>> maliciously modulated signal from an evil server might you might have 
+>>> connected to via your tunnel.
+>>>
+>>> This exploits the behavior of a basic Tor Relay, in which everything 
+>>> that enters a relay must [immediately] leave that relay.  This traffic 
+>>> alone would generate what appears equal/average incoming and outgoing 
+>>> msgs.  Any spikes in the entering / leaving traffic is therefore 
+>>> probably not from the Tor Relay itself, but, from something else.  (or 
+>>> course, this ignorse dir service lookups, bridges, and prly a few other 
+>>> things).
+>>>     
+>>
+>>      Almost.  If you have an asymmetric broadband service and are not
+>> specifying BandwidthRate or BandwidthBurst in torrc, then your tor server
+>> is likely to top out around the transmission rate limit of your Internet
+>> connection.  At this point, only input spikes would be visible.  When data
+>> come in faster than they can go out, the cells just stay in an output queue
+>> until they can be sent.  If this goes on over an extended period of time,
+>> it will have at least a partial smoothing effect upon the inflow as well
+>> due to TCP source quench packets being returned.
+>>      Note also that spikes may occur for several other obvious reasons,
+>> e.g., a new stream on a circuit going through your tor server that is used
+>> for FTP, downloading large files (e.g., music or video or CD/DVD image
+>> files), or NNTP batch transfers.  Spikes often have nothing to do with a
+>> local client.
+>>   
+>Yeah, I guess I was making synchronized assumptions, haha :).  But, I am 
+>having trouble imagining circuit based Tor relay traffic causing 
+>"spikes" in the differences between total incoming traffic and total 
+>outgoing traffic - since, if there were large discrepancies between 
+>these two totals, it would more or less be a kind of measure on your own 
+>relay's lag.  In a low-latnecy system, one of the centric goals is to 
+>minimize this - and in Tor, I believe several design decisions were 
+>based around this.  So, even if things are async, it seems likely that 
+>(large, consistent) discrepancies between total incoming/outgoing 
+>traffic would prly be due to "other" local traffic that either 
+>originates or exits form the relay.  But yes, I was also assuming a 
+
+     My computer spends many hours per day during which tor is the only
+thing doing any significant volume of network traffic.  (The only other thing
+accessing the net at those times that comes to mind is ntpdate running once
+every hour, which is trivial.)  During that time, I see network traffic varying
+widely, especially on the input side.  I'm not doing anything that accesses
+the network at those times, so local use is not a factor.
+
+>strong local passive adversary that is able to distinguish between 
+>circuit relay traffic and all other (ignored) network traffic.
+
+     Actually, the presence of non-tor traffic would just make things more
+difficult.  Remember that exit traffic bears no marks of distinction from
+other locally generated, non-tor traffic.  Traffic generated by other machines
+on the same local net as the tor server machine is not distinguishable by
+IP address if the local net lies behind a NAT+RDR-serving router.  Traffic
+identifiable by port number as being tor traffic appears simply as unidentified
+tor traffic, but its flow rate may be determined as much by the total volume
+of other traffic entering and leaving the local net as by the external and
+local tor-related demand.
+     My lousy ISP (TBC Net, Inc. at www.tbcnet.net) cuts the connection at
                                            ^^^
     The web site address above is incorrect.  It should be www.tbc.net.
My apologies for the noise.

+least once a day, often more than once in a day.  Upon reconnection, the
+IP address assigned has usually changed, but not always.  On the rare occasions
+that the IP address has not changed, it sometimes happens that my tor server
+will get marked as "stable" by the directory authorities in the directory
+information.  After a disconnection and reconnection with the same IP address,
+the traffic rebounds quickly.  As long as the server is not listed as "stable",
+traffic varies a lot around the clock, but in those cases where it gets marked
+"stable", the traffic tends toward a steady, maximum-output-rate load within
+two or three hours of the "stable" listing in the directory.  In this case,
+few, if any, output peaks are possible and output troughs are unusual.  Input
+peaks and troughs are sometimes visible, but due to the maxed out output
+bandwidth, little change appears in the output signal.  In order to see such
+peaks and troughs, one would have to have access to the output queue lengths
+and volumes on the tor server's machine and on any router connecting the local
+net to the Internet.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************