Quoting pwang708 <[email protected]> from ml.gnutella.dev-forum:
:Another thing we really need to consider before we start working on
:the details is security including spam. What security "level" do we
:want to achieve, if it is achievable? Is the security too expensive or
:not... Changing security requirement may trash many good design...
The basic "security" we want in the DHT is to make it harder for spammers
to store improper IP:port values under keys. I say "harder", not impossible.
There are several levels:
Pre-requisites:
* The PONG message should be extended to include the daily uptime of the node.
Same format as the "DU" GGEP extension in the Gnutella Pongs, for instance.
* We must distinguish between original publication and replication of data
by the k-closests neighbours to a key.
* The STORE message must be extended to hold the TTL of the data being stored,
this TTL being decreased at each replication.
We can then perform the following checks:
* At initial publication time:
+ ping the publishing node and trim the TTL to the "DU" (exponential
moving average of the uptime of the node). Also check the KUID is
consistent with the previous one.
+ make sure the published IP:port matches the external address of the
contact.
+ optionally perform semantic checks for file hashes. Assuming the SHA1
of the file is that of the key, perform a HEAD Ping on that SHA1 to
see whether the node shares it. If the key is NOT the SHA1 but a hased
version of it, then the STORE request must include the SHA1 as well and
we must verify the key and the SHA1 do match the hashing policy.
[Bonus question: do we want to store firewalled sources in the DHT, i.e.
include their GUID as values instead of IP:port? This will require another
lookup in the DHT by uses, to find push proxies for that source...]
+ check the frequency at which the node publishes information.
Exceptionally a node can go down before its daily uptime and therefore
can be allowed to republish before the TTL expires, but that should not
be the norm.
[Also note that if we choose to go the "sloppy way", a node will not store
more than a handful of IP:port values for each keys, so STORE will have to
go further from the ideal target. The TTL needs to be adjusted exponentially:
the further from the ideal target, the more the intended TTL must be decreased,
without the publisher being notified of that fact. Spammers trying to flood
the DHT will therefore have problems getting their values remembered]
* At replication time:
+ make sure the replication occurs from a node that is indeed on of the
k-closest neighbour. Caching nodes should not replicate.
+ make sure the TTL is decreasing correctly (with a margin of error since
the scheduling of the republishing can be slightly deferred and the
new TTL not exactly reflect the elapsed time since the previous STORE).
+ ignore replication (but mark data a replicated; i.e. do not republish
your own data before another hour) if you are full already for the key.
If not full, only accept a subset of the data being republished,
most likely the ones with the longer TTL. (This is the sloppyness
of the DHT -- not ALL published data will be remembered, at least for
data which consists of an IP:port).
Checks at publishing time are perhaps more costly to perform but can be
randomly performed by the node. For instance, if the data is the first for
the key, it can be accepted. Them more coming in, then maybe the more we
need to be careful as this could indicate spamming or hostile behaviour
for the key. It can also depend on the perceived "load" on the node.
Raphael
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.