On Thu, Aug 17, 2000 at 09:47:44AM -0500, Scott G. Miller wrote: > > This is more or less correct, a transient node doesn't set the DataSource > > field, so one can see that a transient node has connected. Running a > > transient node is more about performance (keeping your own routing table) > > then adding any real security above just using a plain client. > Really? Thats a bad thing.
It can't really be helped. It could set it's own address as the source, but then it would need to reject connections, which would give it away as well. It could also spoof the DataSource to point at some other node, but since the DataSource on Inserts is reset on every hop that would give it away too. This one of the reasons I would rather we found a better method then reverse sourcing on inserts for node discovery. > Like I said, fingerprint->new IP is okay. But old-ip->new fingerprint > indicates a subversion. I don't think anybody said otherwise though. > > I'm actually warming up the idea of making the address: > > > > physical address + fingerprint + number > > > > and having the node lookup: > > > > ARK(fingerprint , (number + 1)) > > > > should the connect fail (ARK is Address Resolution Key). > This should be done in a background thread not related to the transaction > in which the connect failed, but this isn't a bad idea. An ARK can just > be an SSK too, assuming we select an authentication scheme that dovetails > well. Yes, completely background. At route time, the connection still fails, but instead of simply removing the reference like we do currently it is given to internal thread that attempts to reinstate it through and ARK request. -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
