On Wednesday 27 Feb 2013 18:54:34 Matthew Toseland wrote:
> operhiem1's graphs of probed total datastore size have been attacked recently 
> by nodes returning bogus store sizes (in the multi-petabyte range). This 
> caused a sudden jump in store sizes on the total store size graph. He 
> excluded outliers, and the spike went away, but now it's come back.
> 
> The simplest explanation is that the person whose nodes are returning the 
> bogus stats has hacked their node to return bogus datastore stats even when 
> it is relaying a probe request. Given we use fairly high HTLs (30?) for 
> probes, this can affect enough traffic to have a big impact on stats.
> 
> Total store size stats don't matter that much, but we need to use probe stats 
> for a couple of things that do:
> 1. Pitch Black prevention will require probing for the typical distance 
> between a node and its peers. Granted on darknet it's harder for an attacker 
> to have a significant number of edges / nodes distributed across the keyspace.
> 2. I would like to be able to test empirically whether a given change works. 
> Overall performance fluctuates too wildly based on too many factors, so 
> probing random nodes for a single statistic (e.g. the proportion of requests 
> rejected) seems the best way to sanity check a network-level change. If the 
> stats can be perverted this easily then we can't rely on them, so empiricism 
> doesn't work.
> 
> So how can we deal with this problem?
> 
> We can safely get stats from a randomly chosen target location, by routing 
> several parts of a probe request randomly and then towards that location. The 
> main problems with this are:
> - It gives too much control. Probes are supposed to be random.
> - A random location may not be a random node, e.g. for Pitch Black 
> countermeasures when we are being attacked.
> 
> For empiricism I guess we probably want to just have a relatively small 
> number of trusted nodes which insert their stats regularly - "canary" nodes?
> 
Turns out this is mostly a false alarm; operhiem1's stats weren't excluding 
outliers at all, the sample just fell out of the running average, then came 
back. Also the reject-probe stats shouldn't be significantly impacted by this, 
since they have a limited range.

However it's still worth looking at this.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to