Changes between Version 17 and Version 18 of thesis


Ignore:
Timestamp:
Apr 11, 2011 2:41:12 PM (8 years ago)
Author:
zzz
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • thesis

    v17 v18  
    11Comments on thesis
     2
     3General comments:
     4
     5*please add*
     6
     7
     8
     9Specific comments:
    210
    311Sec. 3.1:
     
    3240
    3341  Unidirectional tunnels as a "bad design decision":
     42   A bold and absolute statement not fully supported by the paper. It clearly mitigates other attacks and it's not clear how to trade off the risk of the attack described here (either currently or after implementing one or more of the recommendations below) with attacks on a bidirectional tunnel architecture.
    3443
    3544  Paper's recommendations:
     
    5059
    5160Sec 7 Conclusion:
    52  1) Timetable of 0.8.4 release:
     61 What the "devs decided":
     62  1) Timetable of 0.8.4 release:
    5363   Released March 2, installed in 25% of network by ~March 4, 50% by ~March 6, 75% by ~March 14 (source http://stats.i2p.to/cgi-bin/total_routers_3month.cgi )
    5464
    55  2) Relevant changes in 0.8.4 release:
     65  2) Relevant changes in 0.8.4 release:
    5666    a) Prevent tunnel-building DOS by a single source. This was done in reaction to the attack.
    5767
    5868    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.
    5969
    60  3) More changes to detect and prevent DOS are upcoming in 0.8.5 (scheduled for release the week of April 18) but these are not a complete solution. A fully distributed tunnel-building DDOS is difficult to prevent completely.
     70  3) More changes to detect and prevent DOS are upcoming in 0.8.5 (scheduled for release the week of April 18) but these are not a complete solution. A fully distributed tunnel-building DDOS is difficult to prevent completely.
     71
     72 Reacting to performance changes as a "bad idea":
     73   A bold and absolute statement not fully supported by the paper. Clearly there are steps we can take to mitigate the attack, especially by detecting and reacting to the DDoS and other items discussed at the end of Section 6. Also, the network is still very small. We aren't making absolute claims about our anonymity especially when the whole network is 2000 - 3000 routers. Yes we still have work to do to ensure anonymity while doing performance-based peer selection and there are tradeoffs involved. But don't write it off as a "bad idea".
    6174
    6275Sec. A.2 Integration value: