Changes between Version 18 and Version 19 of thesis


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

Legend:

Unmodified
Added
Removed
Modified
  • thesis

    v18 v19  
    3737  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)
    3838
    39   Also not discussed - effect of leaseset size (number of leases or inbound tunnels) which is user-configurable from 1 to 7. It also is configurably dynamic, with less leases when the server is idle. A high number of leases makes it quicker for an adversary to enumerate the fast peers.
     39  Also not discussed - effect of leaseset size (number of leases or inbound tunnels) which is user-configurable from 1 to 6. It also is configurably dynamic, with less leases when the server is idle. A high number of leases makes it quicker for an adversary to enumerate the fast peers. I assume you used the default setting of 2 leases for your experimental victim.
    4040
    4141  Unidirectional tunnels as a "bad design decision":
    4242   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.
    4343
     44   Also, given future increases in network size and  implementation of recommendations, the tradeoff of analysis time vs. false-positive rate may change. For example, a 30x increase in analysis time for unidirectional tunnels is not insignificant. What if the fast tier size was increased to 1000? Then the time would be 1000x.
     45
    4446  Paper's recommendations:
    4547
    4648   1) Limit churn:
    47       Possibilities: Increase 45 sec evaluation cycle, increase 30-peer fast max and/or 75-peer high-cap max.
     49      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.
    4850
    4951      Not a possibility: Increasing 10-minute tunnel lifetime (unfortunately it is essentially hard-coded in the network now)
     
    5456   3) Use random peers for leases (guard nodes):
    5557      By this you mean, I think, using random peers outside the fast tier for the inbound tunnel's gateway. We could also keep these peers semi-constant, or more stable, by attempting to recreate the same tunnel at expiration, while still changing them on rejection. This could be done either from the fast pool or by using a random peer.
     58
    5659      Benefits / downsides?
    5760