On Thu, 16 Oct 2003, Toad wrote: > On Thu, Oct 16, 2003 at 12:12:11PM +1000, fish wrote: > > On Wed, Oct 15, 2003 at 07:14:16PM +0100, Toad wrote: > > > Suggestion: > > > What if we were to reject all queries from any node which either has no > > > return address, or we have tried to contact and it has never succeeded > > > and failed more than once? This would substantially discourage nodes > > > from antisocial behaviour, eliminate some useless load, and so on. > > > Especially since what connections they do have will be quickly occupied > > > with trailing fields. That will however change when we have > > > multiplexing, and this would have to be reevaluated. Any suggestions for > > > wider freeloading measures would be interesting too. > > > > Hrm, how would this effect uses who are stuck behind NAT's that they are > > not in a position to work around (and hence a node can never open a connection > > to)? > > They would not be able to make queries. Their network topology forces > them to be freeloaders, and we should treat them as such. Or so the > argument goes. We MAY be able to do some sort of firewall circumvention > system using shadow nodes as discussed elsewhere - but it is relatively > low priority at the moment unless it becomes easy (which it won't until > muxing is in, at least).
Um, Toad? Why not? The whole point of persistant routing table connections is to stop bringup-teardown costs. At that point, what does it really matter who sends the syn packet? A hostile node will bring up a connection, send a query, then close the connection. Not only do we process the query, but we keep trying to contact them. It will also look suspiciously like an older -stable node that did stupid shit like that. With connection multiplexing, why on earth would we refuse a query from a node that we have a routable connection to? I propose that if you want to 'blacklist' nodes you would test for activly hostile behavior, not trivial network hicoughs that we already work around fine with NGR. In this case, a node that connects, sends a query then disconnects. If this happens too frequently blacklist it (exponential growth with a decently sized table) For an example of how this works in the real world, look at BGP flap dampening. Things happen to network connections, but with 100k routable prefixes, it's expensive to make changes. When an interface 'flaps' (Changes from Routable to Not Routable) it gets put into a flap table. If it happens again within X amount of time, it gets dampened (ignored) for an additional X. If it happens AGAIN within that time, it gets 2X added to it's penalty, then 3x, etc. Cap is usually about 24 hours. If you stabilize a noisy interface, about 24 hours later it will be globally routable again. Different backbones have different policies, but that's the general idea. --Dan
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
