Changes between Version 45 and Version 46 of thesis
- Timestamp:
- May 3, 2011 2:01:46 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
thesis
v45 v46 11 11 12 12 << Responses by Michael 2011-05-02 13 14 ***>> zzz 2011-05-03 13 15 14 16 Specific comments: … … 46 48 << Just to be clear, the 64 kB/s limitation comes from Planet-Lab. We would have configured with a higher bandwith, if we could have. I'm not sure it's possible to behave better to some peers. After all, the victim is at the beginning totally anonymous and at the top of my head I can not think about a mechanism that limits tunnel participation of the monitor peers without significantly reducing the possibility to reject tunnel requests of the victim (which would hurt badly). Anyway, I feel like this is a small detail for our work. 47 49 50 ***>> Yeah, not so much an issue for the paper, but something for us to think about. 51 52 48 53 Table 5.2: The network size is estimated to be about 2500 uniques per day, and about 6000 - 7000 uniques per month (source http://stats.i2p.to/cgi-bin/total_routers_3month.cgi ) 49 54 … … 63 68 << There is a explanation on that in the paper, right? 64 69 70 ***>> Not that I could find - I skimmed the paper again and also searched for "3-hop" 71 65 72 "for the duration of the measurement": How long was it? minutes, hours, days? The time-to-deanonymize would be good to include here. It isn't clear if you deanonymize in one tunnel lifetime (10 minutes) or it takes multiple successful placements of the monitor peers over a long time period. 66 73 … … 75 82 < We don't need a constant number of monitors in the victim's fast tier all the time, and obviously this depends on how many attackers, how many monitors, how fast the rest of the network is AND on the configuration of the victim. Too many factors for a controlled experiment with a clear answer. What we show is that an adversary controlling X% of your network can use a DoS on the fast tier-estimate to have MORE than X% of his peers in the victim's fast tier.[[BR]][[BR]] 76 83 77 **> Right. So we're getting to a much clearer statement of the issues. If an attacker has X% of the network, or X% of the fastest routers, you don't want each to have more of an X% chance of getting into a tunnel, and ideally you want an attack to have less than a X**2 chance of succeeding (two attacking routers in the right place in the tunnels - one ping enough). What we (I2P) wants to do is push the probabilities back to where they should be. As we say on the threat model page, if an attacker owns enough of the network then you are at high risk. 84 ***> Following paragraph reworded. 85 **> Right. So we're getting to a much clearer statement of the issues. Let X = c/N where c is the number of attack peers and N is the total network size... or N equals the number of fast peers. If an attacker has X% of the network, or X% of the fastest routers, the network design goal is to prevent an attacker from doing anything to artificially increase the odds of getting into a tunnel to more than X%. Ideally we would like the odds of success of the attack to be X**2, or the effort to be O(X**2) (two attacking routers in the right place in the tunnels - one cell enough). What we (I2P) want to do is enhance our defenses so that the odds really are close to these ideals - in other words, that an attacker cannot influence things to increase his odds of success or reduce the time or effort. As we say on the threat model page, if an attacker owns enough of the network then a user is at high risk (i.e. if X is high enough, X**2 is too high for practical anonymity). 78 86 79 87 << I don't really get this statement. TODO 88 89 ***>> Reworded above 80 90 81 91 In fact, most fast peers are from a Class "O" (greater than 128 KBytes/sec) group of routers and those are about 20% of the network - so there's perhaps 400 peers that could potentially be in the fast group in today's network of 2000 - 3000 routers. … … 91 101 92 102 << So you are not completely sure about this either? I think it's worth and important to figure this out! 103 104 ***>> agreed 93 105 94 106 So isn't this really about an adversary taking over a large proportion of the entire network, or at least of the network's fast routers? Is I2P any more vulnerable at X % hostile peers compared to other networks? Once you have a large number of hostile fast peers in the network, is the traffic analysis of your attack any quicker or more reliable than other attacks, e.g. first and last node in a tunnel (ref: "one ping enough" paper or blog post about Tor) … … 135 147 << I certainly understand your intention to defend uni-directional tunnels. Our main point is: Deanonymizations on uni-directional tunnels take a longer time (fair to say it's an advantage), but we can be way more certain in the uni-directional case (in fact I think this is exactly Complications statement). So, for this work, we do not see an advantage of uni-directional tunnels. Of course just for the researched setting with long living Eepsites. Can you argue with that? The text in the paper now says: "using uni-directional SEEMS to be a bad design decision". Certainly any results disprove this statement are welcome. I hope you're fine with that. 136 148 149 ***>> I appreciate the "seems", but I think we're agreeing to disagree here, which is OK. But since I'm thinking about it now, I'll try one last time, in a single sentence, addressing my point #1 only: Your conclusion is based on your own weighting of the importance of certainty vs. time, and that weighting may be wrong, and it's definitely debatable, especially in a real world with subpoenas, search warrants, and other methods available for final confirmation. 150 137 151 Once the attacker's routers are a large portion of the victim's fast tier (e.g. 'one ping enough'), all sorts of analysis and attacks are possible, and many would be the same or easier with bidirectional tunnels. While we appreciate the innovation of your timing analysis attack with our unidirectional tunnels, the victim is eventually owned via any number of attacks when his fast tier is overtaken. 138 152 … … 152 166 153 167 << Okay, will do the same. 168 169 ***>> I'll comment briefly here but I've moved further discussion of countermeasures to http://zzz.i2p/topics/895 . 154 170 155 171 1) Limit churn: … … 161 177 162 178 << I think this hurts the performance of I2P very much. Assume you limit the change rate of the IBGW and they are under attack. What would happen when they start to perform worse? Would you still use them? 179 180 ***>> Sure, that's the problem with any fixed or semi-fixed strategy. You eventually have to switch if they get attacked or simply vanish. The slower you want to change, the worse performance you suffer with before you finally do switch. See http://zzz.i2p/topics/895 for more discussion. 163 181 164 182 Not a possibility: Increasing 10-minute tunnel lifetime (unfortunately it is essentially hard-coded in the network now) … … 245 263 << My main goal was not to refer to a performance/anonymity trade off. Yes, there is the possibility that if you react quickly on performance changes you end up with a higher overall performance. But at least I feel like you can easily change some behavior (45s evaluation cycle) without risking to end up in a really bad overall performance. This is a very general statement, which (I think) our paper shows. I'm not sure we criticize I2P here. 246 264 247 **> There's been a lot of research ("one pingenough", etc) on the perils of rapidly changing the peers and peer positions in tunnels. I2P has benefitted from and learned from this research - we use strict ordering of peers in tunnels, we have a 24 hour window for stats, etc., to limit the speed of change. So we are certainly aware of the issue, even as we know we currently have much more frequent tunnel peer change than Tor. However with a lack of guard nodes, lack of constant leases (entry nodes), and fairly rapid fast tier replacement when the fast tier is DDoSed, it appears that the current implementation does react too quickly.265 **> There's been a lot of research ("one cell enough", etc) on the perils of rapidly changing the peers and peer positions in tunnels. I2P has benefitted from and learned from this research - we use strict ordering of peers in tunnels, we have a 24 hour window for stats, etc., to limit the speed of change. So we are certainly aware of the issue, even as we know we currently have much more frequent tunnel peer change than Tor. However with a lack of guard nodes, lack of constant leases (entry nodes), and fairly rapid fast tier replacement when the fast tier is DDoSed, it appears that the current implementation does react too quickly. 248 266 249 267 << I think it's fair to say, that I2P has some room of improvement here. 268 269 ***>> :) 250 270 251 271 Sec. A.2 Integration value:
