> We would have to put the information in public metadata. But then
> that opens a range of evil attacks, like an evil person inserting
Stop right there. Let's first define what a successful attack on
Freenet would be. That means we need to figure out what we're
protecting. Freenet's goals, as I understand them, are about like
this:
- Distributed, dynamic mirroring
- Pseudo-anonymous access
- Encryption support (plausible deniability) for clients
- No centralized control ("There is no off switch")
Those are the big ones. So now we know what resources we are
protecting, namely:
- Bandwidth
- Anonymity
- Server utilization
Bandwidth
The more servers, the less likely a single DDoS attack is to derail
the network. That aside, several measures could be incorporated
to reduce the risk of DoS - limit the size and number of the initial
packets sent for a "handshake" for the server. Provide a method of
verifying the IP address the server is sending to has a freenet
client on it, and was the initiator of the request. Also, not having
a way of discovering all the servers on the freenet network would
effectively increase the apparent size of the network.
Anonymity
This, IMO, is the biggest architectural issue facing Freenet. We
all know once Freenet becomes stable and operational, people are
going to want to monitor what is going on - specifically who is
tranferring what. The RIAA, for example, or the NSA. I don't know
enough about Freenet to comment on how this will be accomplished,
but it is something that *will* be attacked.
Server Utilization
By simply overloading a server with requests, you could grind it
to a halt. For example, if there was a bug in the protocol that
allowed you to request that a file be wrapped in several different
encryption schemes and then sent an attacker could request that a
large file be encrypted with multiple keys - exhausting available
memory.
No Centralized Control
Make sure nobody can find all the servers and/or that they are
geographically dispersed and then don't provide any facilities
to shut them down, and that is that. :) No court order can
shut you down then. Freenet already has this architectured,
so I'll leave it at that.
> a multipart file into Freenet, listing the correct parts in an
> SVK, but then including false information in the public
> metadata of those parts. Nodes would then be oblivious to the
> fact they are parts of the same file, and the node would be
> open to attack.
First, if a piece of data is invalid, it won't be requested. If
it isn't being requested, it dies off the network. Freenet has
no facilities to allow data to live forever. Secondly, simply
having the server calculate the public metadata would eliminate
this. md5sum every piece of data on the server, and "hardlink"
duplicates.. or remove them. Or query another server. Either way,
you can maintain referential integrity without trusting a remote
user.
Think of Freenet as a distributed database - you have a primary
key which is unique to that piece of data (as any RDBS will have
these days). Simply make the key data-dependent (md5sum) and you
eliminate duplication. A side-effect of this is you then need to
block the data to discrete sizes (1k, 2k, 4k, whatever). From
a performance standpoint, however, I can't complain - it would
make seeking through the database (or cache, or file, whatever)
less resource-intensive.. since you know the offset ahead of time,
instead of having to seek to it.
~ Signal 11
... if that made any sense, you get 2 points. If you actually code
something out of that, I'll pay for the first visit to your
psychologist. :) (shamelessly stolen from a recent /. article)
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
