A small set of ideas that Nick and Roger suggested I write up regarding bridge detection.

svn:r19355

1 files changed, 76 insertions, 0 deletions

diff --git a/doc/spec/proposals/ideas/xxx-port-knocking.txt b/doc/spec/proposals/ideas/xxx-port-knocking.txt
new file mode 100644
index 0000000000..04bbc7d453
--- /dev/null
+++ b/doc/spec/proposals/ideas/xxx-port-knocking.txt
@@ -0,0 +1,76 @@
+Filename: xxx-port-knocking.txt
+Title: Port knocking for bridge scanning resistance
+Version: $Revision$
+Last-Modified: $Date$
+Author: Jacob Appelbaum
+Created: 19-April-2009
+Status: Draft
+
+            Port knocking for bridge scanning resistance
+
+0.0 Introduction
+
+This document is a collection of ideas relating to improving scanning
+resistance for private bridge relays. This is intented to stop opportunistic
+network scanning and subsequent discovery of private bridge relays.
+
+
+0.1 Current Implementation
+
+Currently private bridges are only hidden by their obscurity. If you know
+a bridge ip address, the bridge can be detected trivially and added to a block
+list.
+
+0.2 Configuring an external port knocking program to control the firewall
+
+It is currently possible for bridge operators to configure a port knocking
+daemon that controls access to the incoming OR port. This is currently out of
+scope for Tor and Tor configuration. This process requires the firewall to know
+the current nodes in the Tor network.
+
+1.0 Suggested changes
+
+Private bridge operators should be able to configure a method of hiding their
+relay. Only authorized users should be able to communicate with the private
+bridge. This should be done with Tor and if possible without the help of the
+firewall. It should be possible for a Tor user to enter a secret key into
+Tor or optionally Vidalia on a per bridge basis. This secret key should be
+used
+
+1.x Issues with low ports and bind() for ORPort
+
+Tor opens low numbered ports during startup and then drops privileges. It is
+no longer possible to rebind to those lower ports after they are closed.
+
+1.x Issues with OS level packet filtering
+
+Tor does not know about any OS level packet filtering. Currently there is no
+packet filters that understands the Tor network in real time.
+
+1.x Possible partioning of users by bridge operator
+
+Depending on implementation, it may be possible for bridge operators to
+uniquely identify users. This appears to be a general bridge issue when a
+bridge operator uniquely deploys bridges per user.
+
+2.0 Implementation ideas
+
+This is a suggested set of methods for port knocking.
+
+2.x Using SPA port knocking
+
+Single Packet Authentication port knocking encodes all required data into a
+single UDP packet. Improperly formatted packets may be simply discarded.
+Properly formatted packets should be processed and appropriate actions taken.
+
+2.x Using DNS as a transport for SPA
+
+It should be possible for Tor to bind to port 53 at startup and merely drop all
+packets that are not valid. UDP does not require a response and invalid packets
+will not trigger a response from Tor. With base32 encoding it should be
+possible to encode SPA as valid DNS requests. This should allow use of the
+public DNS infrastructure for authorization requests if desired.
+
+2.x Additional considerations
+
+There are many. A format of the packet and the crypto involved is a good start.