One related detail: At present: - At HTL=1, we have a 20% chance of terminating the request. This is to prevent various probing and social engineering attacks (or to make them harder and less reliable). On average 5 extra hops. - At HTL=max (10), we have a 10% chance of decrementing. This is to provide some level of anonymity (it is not enough against correlation attacks etc, but it does make it harder for an attacker). On average 10 extra hops.
I suggest that we increase both probabilities: - At HTL=1, a 25% chance of terminating the request. (We still need to keep some extra hops, and towards the end, we won't get many "natural" extra hops from resetting due to getting closer to the target). - At HTL=max, a 50% chance of decrementing the request. (We will get many "natural" extra hops near the beginning. If we ever expose the full network topology with locations, we should reduce this significantly). - Default HTL=5 as Ian suggested. Any objections? On Thu, Sep 22, 2005 at 11:07:06PM +0100, Matthew Toseland wrote: > I have had some lingering doubts about subscription requests and HTL. > > Here is a solution: > - We have already decided that the root node is the node which cannot > find a closer node to the target within a certain HTL hops. > - We can logically extend this: the root node is the node which cannot > find a closer node to the target within maxHTL hops. > - It therefore follows: We route the subscribe request as normal, > decrementing HTL when we don't get closer to the target. The closest > node found will then get a DNF back from the rest of the chain. If it > sent the request onwards at full HTL, it immediately knows it is root. > If it did not, it resends the request at full HTL. If *that* produces > a DNF, the node knows for sure that it is the root. If it produces a > SubscribeSuccessfulNewRoot, we have found a new root; if it produces a > SubscribeSuccessful, we have found an existing route downstream (which > should be a rare event). > > /me wonders what sort of routing churn this is going to survive... > > Obviously there are attack vectors, but there are attack vectors on > requests and especially inserts - you can just swallow an insert, for > example. This is made much worse by the new routing algorithm, but we > will try to find ways to secure it against internal attackers... > eventually. > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/tech -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20050923/d8ee4f0a/attachment.pgp>
