Most recent edit on 2008-04-29 21:07:35 by DaveBaker [-]

Additions:
ULPRs can be used via FCP by setting the MaxRetries parameters to -1.

---

Edited on 2007-12-20 00:08:29 by MatthewToseland [formatting]

Additions:

Ultra-Lightweight Passive Requests

Security issues

Deletions:
Security issues:

---

Edited on 2007-12-20 00:08:05 by MatthewToseland [security issues]

Additions:
Security issues: [freenet-dev] ULPR data structures: security issues?
Date: Thu, 20 Dec 2007 00:03:46 +0000
Message-Id: <200712200003.51570.toad@amphibian.dyndns.org>
Consequences for ULPRs and passive requests:
When the top block is inserted, ULPRs can tell us immediately. We download the
top block. That tells us the keys of the second layer. However, if we bust
nodes in the right areas, they will not tell us anything about it, at least
not from their ULPR data structures, because those structures are deleted
when the data is found. (Obviously as with many places in the node it is
possible that there are un-garbage-collected remnants...)
On the other hand, can ULPR data structures tell us anything about a request?
Well, ULPRs, in the current half-finished implementation, record the nodes
that requested the key, the time at which they requested it (so they can
expire), the boot IDs of the nodes at the time (so they can be dumped if the
node restarts), the nodes we routed the requests to, their locations, boot
IDs and times (so we can reject requests when the key has already been routed
to the best node for it). If an attacker can bust a bunch of nodes that were
involved in a request, he may be able to use this to try to trace the key's
requestors. However, if the key is found, he has nothing, since it is
forwarded and the ULPR structures are deleted (except the UID of the request,
which will tell him whether or not a node participated in a specific request;
this is essential to prevent loops).
So against an attacker that can compromise nodes at will (while not
necessarily owning all of them at any one time), ULPRs may enable him to
trace previous unsuccessful requests. However, this only makes a difference
for hit-and-run inserts: If there is any sort of ongoing anything, he can
simply compromise nodes, plant whatever logging is needed, and wait. And then
only if he is not able to permanently compromise a large fraction of the
network in preparation for needing to do a trace. Most of the above data is
vital afaics. We could eliminate the requestor part of it by offering any
newly found data to ALL of our peers, but in the short term this would
definitely make the situation worse for local attackers. In the long term, we
probably will go in this direction: publishing Bloom filters for the data in
our store to our trusted darknet peers for a few hops (even for one hop)
would be a significant optimisation, and announcing the key to all our peers
when we find data is essentially that.

---

Edited on 2007-08-09 20:03:21 by MatthewToseland [link to SimpleExpendablePassiveRequests]

Additions:
Also see PassiveRequests. ULPRs are "ultra-lightweight" because they make no attempt to guarantee that the key is found: they are unreliable, and rely on the client continuing to poll for the key (although they drastically reduce the total cost of such polling for popular keys). Similar to SimpleExpendablePassiveRequests, but more efficient because of failure tables.

Deletions:
Also see PassiveRequests. ULPRs are "ultra-lightweight" because they make no attempt to guarantee that the key is found: they are unreliable, and rely on the client continuing to poll for the key (although they drastically reduce the total cost of such polling for popular keys).

---

Edited on 2007-06-15 21:43:47 by MatthewToseland [contrast with passive requests]

Additions:
Also see PassiveRequests. ULPRs are "ultra-lightweight" because they make no attempt to guarantee that the key is found: they are unreliable, and rely on the client continuing to poll for the key (although they drastically reduce the total cost of such polling for popular keys).

Deletions:
Also see PassiveRequests.

---

Oldest known version of this page was edited on 2007-06-15 21:41:54 by MatthewToseland [not much here]
See basic description on FailureTables page.

Also see PassiveRequests.

Also see this bug∞.