On Mon, Dec 25, 2000 at 03:12:24PM -0600, Brandon wrote:
>
> > The entire Freenet mechanism depends upon the "path compression" effect
> > which you get when data is requested, however (as was pointed out the last
> > time this was suggested) with this mechanism this path compression would
> > not occur.
>
> Freenet does not rely on path compression. Path compression optimizes
> Freenet by making it closer to being fully connected. Inside the cluster
> it's fully connected anyway. Outside of the cluster, path compression
> happens between normal nodes and cluster gateways. A cluster appears just
> like any other node. Nothing bad happens to the network topology just
> because path compression doesn't happen between nodes inside and outside
> of a cluster! If a file is retrieved from a file inside the cluster, the
> DataSource will be set to the gateway. This is fine. The gateway might
> cache it anyway. If not, then it will add only 1 to the necessary HTL
> since the gateway is one hop away from all of the nodes in the cluster.
Oh no. Freenet *relies* on path compression. Without it you can't use a
linear search to get data. A couple of studies have been done on
small-world networks like Freenet, where its shown that without far
reaching links (created by path compression) they fail. One is included
in an upcoming orielly book on P2P. Creating a cluster means that you
have to increase the overall htl by the size of the cluster in order for
requests into the cluster to work. This can be done by having the gateway
increase the htl when it receives a message. Likewise, outbound requests
have to have the same pattern unless you create a star-network type
cluster, which has a central point of failure.
Now, imagine three clusters (just three little clusters) of maximum width
10 exist on Freenet, and a request hits all three of them. With HTL 15,
each gateway has to increase the HTL by 10 to make it appear as one node
(as you so fondly suggest a cluster is). That means that you have an
effective HTL of 45 for this request. Is it just me, or is that an
unreasonably long time to wait for data? As Ian has pointed out., what
this is doing is turning Freenet into loosely grouped Gnutellas with
terrible search efficiency. And for questionable benefit.
Media-enforcer attacks are closed with P/K and varying htl decrements. So
quit harping up on that. Hostile-territory Freenets need to deal with
this problem more thoroughly, with solutions outside of Freenet
(super-paranoia stuff like stego).
> case you don't talk to the public network, so there is still no problem.
>
> The problem which Scott pointed out is that a message sent into a cluster
> will bounce around in the cluster, absorbing a lot of HTL. While this
> won't be a problem unless there are a lot of clusters bunched together,
> which probably won't happen. However, even so, a slight tweaking is
> probably possible to eliminate this problem entirely. The particulars
> would need to be worked out of course, but basically if you could tweak
> the routing for messages coming into a cluster so that it would only ask
> one node in the cluster and the pop back out into the public network. Then
> a cluster would act exactly like a node, a very large node run on multiple
> computers.
Which would only work for small clusters, since you should need more than
one hop to find data in any non-tiny cluster. (Chinese dissidents are
going to have more than a few nodes).
>
> This doesn't help at all since MediaEnforcer scans blocks of IP addresses
> and therefore doesn't use inform.php in the first place.
Solved by pk.
> > key encryption mechanism rather than DH key-exchanges is another.
>
> This doesn't make any kind of difference at all.
Correct. I'm sure they're willing to wait, but again, not a problem per
above.
>
> Let's say you're the Chinese government instead. The chance of shutting
> down a Freenet node if you find one would be 100% if you decided that
> Freenet nodes were bad.
>
> > b) Using a mechanism where it is possible to tie IP addresses to customers
> > (ie. not cable)
>
> Except if you can't tie a user to an IP address, of course, but you can in
> many schemes. For instance if you keep logs of your DHCP transactions then
> it's not a big deal, even on cable.
Having a cluster wouldn't really help you. They'd find the gateway, kill
the leader, but only after torturing him to get his nodes.config for the
list of the other nodes in his cell. You need more than just this
clusters hack to prevent it.
Scott
PGP signature
