On Friday 27 August 2010 12:22:05 am Matthew Toseland wrote:
> Currently, an attacker can run a malicious seednode, send us it, and then
>  get connected to a large proportion of new nodes, use bogus identities to
>  keep connections to the node, and observe their traffic. He is limited
>  mainly by resources - does he have the ability to connect to all those
>  nodes for long enough to identify whether they are interesting? For
>  hit-and-run, an important use case that Freenet has never been any good at
>  but which is very interesting in practice, he wouldn't necessarily have to
>  keep connections open long term either...
> 
> We can of course increase costs by requiring nodes to be on different /8's
>  or /16's etc, but this only slightly increases costs. Some sort of onion
>  routing involving peers found via different seednodes would be possible,
>  but clunky as later on seednodes don't really matter, and extremely
>  expensive.

I disagree. It would make the stuff a lot more annoying to set up and it would 
be easy to implement.
OTOH it might seriously screw performance because it would probably cause 
peers to be chosen from bad locations internet-topology-wise: Countries like 
germany have *HUGE* ISPs which resell their infrastructure to smaller ISPs so 
most german users will probably be in same subnet of some order. (I have not 
checked whether that actually is the case, I'm guessing) ... If we limit 
connections based on subnets, peers might always be chosen from different ISPs, 
leading to bad performance...
Maybe the set of possible peers could even get exhausted...

> Taking Tor's approach and having a large list of automatically gathered
>  seeds, and only giving a subset to each announcee, doesn't really solve
>  the problem either: The attacker can simply run loads of slow seeds.

It would be very useful to have though, given the fact that we have very few 
seed nodes and each of them is under very heavy load. My seednode is 
constantly seeding 180 peers.

We could even change fred's behavior to auto-enable seednode mode if the node 
detects that
- its opennet port is open
- it's IP stays constant for >N days OR it has a constant host name (=dyndns)

That would probably give us a load of seednodes, which would certainly help 
security AND improve the announcement speed because the seednodes would not be 
under very heavy load. This would also help the first time usage experience.

AND it would cut down our seednodes.fref manual maintenance cost to 0.

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

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

Reply via email to