Changes between Version 44 and Version 45 of thesis

May 2, 2011 4:38:04 PM (9 years ago)


  • thesis

    v44 v45  
    1010**> Responses by zzz 2011-04-26
     12<< Responses by Michael 2011-05-02
    1214Specific comments:
    4244**> Hmm that's discouraging. Obviously the attack is more powerful if the monitor peers don't need to be high-bandwidth. I think what we are seeing is the potential of attacks where the monitors are only "nice" to potential victims, as a way of appearing fast to that victim and getting into their tunnels quicker (even if that's not exactly what you did). In any case, I'm surprised that it didn't take more bandwidth and will have to look into it further. As you know the primary defense against DDos is to increase resource requirements and we have to figure out how to do that.
     46<< 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.
    4448Table 5.2: The network size is estimated to be about 2500 uniques per day, and about 6000 - 7000 uniques per month (source )
    5761**> I didnt expect you would have time to run more experiments; but since your victim was not using the default 3-hop tunnels, some explanation of why you chose shorter hops, and a prediction of how the results would change (if at all) with 3-hop tunnels is clearly appropriate.
     63<< There is a explanation on that in the paper, right?
    5965    "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.
    7177**> 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.
     79<< I don't really get this statement. TODO
    7381  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.
    8290**> So maybe what this all means is that in the normal operating case, most of the fast tier peers are actually fast, but in an attack scenario, relatively low-bandwidth peers could still still get into the tier relatively quickly, especially if they are "nice to the potential victim" (see above in discussion of monitor peer bandwidth).
     92<< So you are not completely sure about this either? I think it's worth and important to figure this out!
    8494  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)
    96106**> Oops, of course you are right, I understood that both before and after I wrote that comment but not during :)
     108<< That happens. :)
    98110  Unidirectional tunnels as a "bad design decision":
    121133**> 4) In summary, "bad design decision" is clearly (to me anyway, since you have not labeled bidirectional tunnels "bad") shorthand for "unidirectional tunnels are unequivocally inferior to bidirectional tunnels", yet this statement is not supported by the paper, nor do I think it was the intended scope of the project.
     135<< 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.
    124137   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.
    138151**> Note that my original comments below are not necessarily suggestions for your paper, some are just thinking out loud about countermeasures.
     153<< Okay, will do the same.
    140155   1) Limit churn:
    145160**> I guess I used "churn" loosely or perhaps redefined it - I was thinking both about one possible goal, which is to limit the rate of change of Inbound Gateway (IBGW) routers, i.e. leases, to slow down fast tier enumeration. And another goal, the more general reduction of the rate of change of tunnel participants.
     162<< 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?
    147164      Not a possibility: Increasing 10-minute tunnel lifetime (unfortunately it is essentially hard-coded in the network now)
    157174**> Tahoe-LAFS is of course just one of a number of possible distributed or DHT-style file systems that could be overlaid on the I2P base technology. It's been said that I2P won't really be complete until we have a solution here. Maybe that's true. But certainly we want to make hosting of a service on a single router as robust and anonymous as we can make it.
     176<< Noted. Distributing (dynamic) content is very difficult to handle and a hot topic for research, so I can understand this statement. Of course you'll suffer from the service being online a very long time on the same machine. But that's maybe the price you have to pay to not run into other problems.
    159178   3) Use random peers for leases (guard nodes):
    207226**> Right. What I meant to say in a) above, (and I elaborated the details in a conversation with you) was a limit on the number of tunnels that can be built in a specific time frame with a single peer as the previous or next hop. These limits are fairly low, such that it will take a large number of peers. This number may be more or less than 40 depending on the capacity of the victim. You were (I think) building one-hop tunnels in the attack. The new restrictions can be evaded by building longer tunnels, with a variety of other peers in intermediate hops. So the new restrictions add some marginal cost but are not a complete solution.
     228<< I see. As far as I remember did you mention that peers reject tunnel participation requests after this low limits are exceeded. You may want to ignore such requests. Note: We do not care about number of tunnel participation. We merely induce traffic on the other node by tunnel requests. So if that peer still uses bandwith the DoS attack might still work.
    209230    b) Penalize peers more due to tunnel rejections. This did not change the time constants of the capacity formulas, just changed (a + r) to (a + 2r) in the denominator of the formula in section A.1. However it may have had the effect of reacting faster to a DOS attack. This change was not made in reaction to the attack, but was previously planned and is part of a strategy to spread the traffic across more peers in the network and adjust the forumla in response to network conditions that have changed markedly in the past two years.
    222243**> I think what you are trying to get across is that there is, of course, an anonymity/performance tradeoff in how fast a router reacts to peer performance changes and that I2P has not correctly balanced that, that we need to react (much?) more slowly than we do now. I don't think that nuance is reflected in "This work shows that peers reacting, and especially reacting quickly, to changes in observed network performance can be a bad idea for anonymizing networks."
     245<< 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.
    224247**> 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.
     249<< I think it's fair to say, that I2P has some room of improvement here.
    226251Sec. A.2 Integration value: