Version 5 (modified by zzz, 8 years ago) (diff)


Comments on thesis

Sec, 4.1: Long paths might be much harder than in ref. 22, our limit is 7 hops max and there are restrictions preventing a peer in the previous and next hop. More complex long paths may be possible.

Fig. 4.2: outbound tunnel labeled as inbound

Table 5.5: What about 3-hop, which is the default for eepsites?

Sec 6 Discussion:

The I2P network is still relatively small but is growing quickly. How about a prediction or sensitivity analysis for a network 10X, 100X larger?

Paper's recommendations:

1) Limit churn:

2) Distributed HTTP services:

3) Use random peers for leases (guard nodes):

Sec 7 Conclusion:

1) Timetable of 0.8.4 release:

Released March 2, installed in 25% of network by ~March 4, 50% by ~March 6, 75% by ~March 14 (source )

2) Relevant changes in 0.8.4 release:

a) Prevent tunnel-building DOS by a single source. This was done in reaction to the attack.

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 forumla 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.

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.