Changes between Version 45 and Version 46 of thesis


Ignore:
Timestamp:
May 3, 2011 2:01:46 PM (8 years ago)
Author:
zzz
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • thesis

    v45 v46  
    1111
    1212<< Responses by Michael 2011-05-02
     13
     14***>> zzz 2011-05-03
    1315
    1416Specific comments:
     
    4648<< 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.
    4749
     50***>> Yeah, not so much an issue for the paper, but something for us to think about.
     51
     52
    4853Table 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 )
    4954
     
    6368<< There is a explanation on that in the paper, right?
    6469
     70***>> Not that I could find - I skimmed the paper again and also searched for "3-hop"
     71
    6572    "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.
    6673
     
    7582< 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]]
    7683
    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).
    7886
    7987<< I don't really get this statement. TODO
     88
     89***>> Reworded above
    8090
    8191  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.
     
    91101
    92102<< So you are not completely sure about this either? I think it's worth and important to figure this out!
     103
     104***>> agreed
    93105
    94106  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)
     
    135147<< 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.
    136148
     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
    137151   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.
    138152
     
    152166
    153167<< 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 .
    154170
    155171   1) Limit churn:
     
    161177
    162178<< 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.
    163181
    164182      Not a possibility: Increasing 10-minute tunnel lifetime (unfortunately it is essentially hard-coded in the network now)
     
    245263<< 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.
    246264
    247 **> There's been a lot of research ("one ping 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.
     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.
    248266
    249267<< I think it's fair to say, that I2P has some room of improvement here.
     268
     269***>> :)
    250270
    251271Sec. A.2 Integration value: