Proposal 109: No more than one server per IP address [was Re: Sybil Attack Countermeasures]

[Nick Mathewson]

I've added the original proposal as "109-no-sharing-ips.txt", retitled
it to No more than one server per IP address, and merged in Roger's
suggestions (except for those that represent an alternative approach;
I've put those at the end).

My rationale for the name change was:
  - We'll eventually want to do something even more smart to detect
    some kinds of Sybil attacks.  When we do, we won't want to have
    a "sybil-checking.txt", a "more-sybil-checking.txt", and a
    "revised-sybil-checking.txt".
  - This isn't actually a test for Sybil attacks per se: it's only a
    break on Sybil attacks by an attacker who can't get lots of IP
    addresses.

On Sun, Mar 11, 2007 at 05:28:54AM -0400, Roger Dingledine wrote:
 [...]
> Should we consider enforcing this on /16 networks rather than /32, like
> we already do for servers-in-the-same-circuit? In many cases being next
> door too isn't so much harder.

This isn't such a good idea; /16s are much bigger geographically in
some places than others.  For example, here's our current top-5 /16s, along
with their count of networkstatus entries:

  12 62.75
  13 85.25
  15 81.169
  22 88.198
  30 85.214

If we do /24 instead, the top 6 are:

  3 18.244.0
  3 217.20.117
  3 85.31.187
  3 88.211.140
  4 85.214.29
  5 149.9.0

> Also, if we're trying to avoid letting the adversary attract too much
> bandwidth, should we be thinking "no more than 5MB/s advertised bandwidth
> total" rather than "no more than 5 servers total"? On the other hand,
> there are a very few cases where we choose a random node without regard
> for advertised bandwidth, so maybe number-of-servers would be good
> too.

Two caps sound best: one on total BW-per-IP and one on servers-per-IP.

 [...]
> None of these are super compelling, other than the first, and I guess we
> could make an 'exceptions' list, though that would be code bloat. I'd be
> more comfortable putting the limit pretty high though (say, 5 servers
> or 5MB/s to start), because that will still block Sybils yet give us
> some flexibility to see how Tor use evolves.

Please, don't say "block Sybils" here.  Remember, the Sybil attack
says nothing about requiring the adversary to have a nicely limited
number of IP addresses.

> > Specification:
> > 	We propose that the directory servers check if an incoming Tor router
> >     IP address is already registered under another router. If this is 
> >     the case, then prevent this router from joining the network.
> 
> By "registered", do you mean "Named"? Or just "Running"? Or just "in the
> network status"?

Another problem at this point:  there is a race here.  Suppose there are
two servers running on some IP address, A and B.  Suppose that A
publishes to directory authority AUTH1 before B does, but that B
publishes to directory authority AUTH2 before A does.  Now AUTH1 will
reject B as a Sybil, but AUTH2 will reject A as a Sybil.  That's no
good; we probably need a different rule to keep the authorities from
getting arbitrarily out of sync with each other.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070311/3b4858cc/attachment.pgp>