Tracking Blocked Ports

[Robert Hogan]

Motivation:
Tor clients that are behind extremely restrictive firewalls can end up waiting
a while for their first successful OR connection to a node on the network.
Worse, the more restrictive their firewall the more susceptible they are to
an attacker guessing their entry nodes. Tor routers that are behind extremely
restrictive firewalls can only offer a limited, 'partitioned' service to other
routers and clients on the network. Exit nodes behind extremely restrictive
firewalls may advertise ports that they are actually not able to connect to,
wasting network resources in circuit constructions that are doomed to fail at
the last hop on first use.

Proposal:

When a client attempts to connect to an entry guard it should avoid further
attempts on ports that fail once until it has connected to at least one entry
guard successfully. (Maybe it should wait for more than one failure
to reduce the skew on the first node selection.) Thereafter it should
select entry guards regardless of port and warn the user if it observes that
connections to a given port have failed every multiple of 5 times without
success or since the last success.

Tor should warn the operators of exit, middleman and entry nodes if it observes
that connections to a given port have failed a multiple of 5 times without 
success or since the last success. If attempts on a port fail 20 or more times 
without or since success, Tor should add the port to a 'blocked-ports' entry 
in its descriptor's extra-info. Some thought needs to be given to what the 
authorities might do with this information.

Related TODO item:
    "- Automatically determine what ports are reachable and start using
      those, if circuits aren't working and it's a pattern we
      recognize ("port 443 worked once and port 9001 keeps not
      working")."


I've had a go at implementing all of this in the attached.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: porttracking.diff
Type: text/x-diff
Size: 15988 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20081014/ef461302/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20081014/ef461302/attachment.pgp>