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

Comments on thesis

Sec. 3.1:

A routerInfo does not contain a "self-signed certificate". It contains a pair of public keys and a "null certificate", which is really just a placeholder for future stuff. It is, however, signed by one of the router's private keys.

Sec. 3.3 Eepsites:

The "identifier" (what we call a "destination") is actually 387 bytes in binary and 516 characters when encoded in Base 64, not 517 bytes. Leasesets are looked up in the netDB using the 32-byte SHA256 Hash of the destination.

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.

Actually I2P doesn't use peers from the same /16 in the same tunnel. Since your attack doesn't require two attackers in the same tunnel, the /16 restriction may not be relevant here.

Fig. 4.2: outbound tunnel labeled as inbound; The "monitor peers" from Fig. 4.1 with red and black stripes are now labeled "A" in this figure, which is confusing.

Sec. 5:

You say that each peer was configured for 64 KBps max but isn't that true only for the 40 attack peers? What was the bandwidth configuration for the 30 monitor peers? Was 64 KBps really high enough to be included in the victim's fast tier?

Figures 5.4 and 5.5: What's the difference between these two figures? Just two different examples?

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? The analysis starts with "a" monitor peers out of the victim's fast pool of 30 peers. There's no analysis or discussion of how many monitor peers of a given bandwidth you need in the entire network to attain the number "a" in the victim's fast tier.

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.

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)

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.

Unidirectional tunnels as a "bad design decision":

Paper's recommendations:

1) Limit churn:

Possibilities: Increase 45 sec evaluation cycle, increase 30-peer fast max and/or 75-peer high-cap max.

Not a possibility: Increasing 10-minute tunnel lifetime (unfortunately it is essentially hard-coded in the network now)

2) Distributed HTTP services:

This is supported via "multihoming", whereby multiple routers may host an eepsite. This requires some additional setup, and of course requires the user to operate multiple routers. Truly distributed hosting is under development through a port of the tahoe-lafs distributed file system to I2P.

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

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. Benefits / downsides?

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

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.

Sec. A.2 Integration value:

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.