Changes between Version 38 and Version 39 of thesis


Ignore:
Timestamp:
Apr 26, 2011 2:51:41 PM (9 years ago)
Author:
zzz
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • thesis

    v38 v39  
    125125  Paper's recommendations:
    126126
     127**> Note that my original comments below are not necessarily suggestions for your paper, some are just thinking out loud about countermeasures.
     128
    127129   1) Limit churn:
    128130      Possibilities: Increase 45 sec evaluation cycle, increase 30-peer fast max and/or 75-peer high-cap max. Downside: larger group makes it more likely for an attacker to eventually be in a tunnel.
     
    130132< We did not suggest to simply change the tier sizes or evaluation cycles.  The suggestion was rather to limit churn, for example by saying that per evaluation cycle, only one peer can be removed from a given tier (adding more might be OK during startup).  You might impose further limits, for example that at most 5 peers can be removed (and not re-added) within 10 cycles, etc.  That would force the adversary to maintain any DoS for longer, still allow you to have the "fast" tier be small and fast AND possibly help your network stability.  45s might also be a bit fast, but changing that value alone would neither be enough nor go to the heart of our suggestion.[[BR]][[BR]]
    131133
     134**> 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.
     135
    132136      Not a possibility: Increasing 10-minute tunnel lifetime (unfortunately it is essentially hard-coded in the network now)
    133137
     
    146150
    147151< You seem to confuse guard nodes (those closest to the victim) and 'entry nodes' (those advertised in the leaseSet).  Our suggestion was to pick a completely RANDOM (not-tier, not-fixed) node for the 'entry nodes', so that the adversary cannot learn about your fast tier from the leaseSet. Obviously, there are trade-offs involved.[[BR]][[BR]]
     152
     153**> yes, I was using "guard nodes" loosely. See above also.
    148154
    149155      Benefits / downsides? What happens if an adversary attacks guard nodes (either in I2P or Tor)?
     
    201207< That was not our statement.  We said that reacting to performance changes *quickly* was a bad idea.  This refers to the (somewhat theoretical) possibility of the entire I2P fast-tier being replaced by other peers quickly IF the adversary targets the right victims with DoS (in practice, as we have shown, the adversary may not be able to determine the correct set of victims that precisely, but your implementation has no 'speed limit' for the evolution of the tiers (ok, 45s...), which is what this is about).  If you limited churn instead (see above), the reaction would take longer, forcing the adversary to maintain the DoS for a longer time.[[BR]][[BR]]
    202208
     209**> 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."
     210
     211**> 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.
     212
    203213Sec. A.2 Integration value:
    204214  This isn't used in I2P for anything except a display and isn't relevant to the paper. You may also wish to remove the information about the well-integrated tier from sections 3.2.4, 3.2.5, and B.1.