proposals/ideas/xxx-port-knocking.txt

   1 Filename: xxx-port-knocking.txt
   2 Title: Port knocking for bridge scanning resistance
   3 Author: Jacob Appelbaum
   4 Created: 19-April-2009
   5 Status: Draft
   6
   7             Port knocking for bridge scanning resistance
   8
   9 0.0 Introduction
  10
  11 This document is a collection of ideas relating to improving scanning
  12 resistance for private bridge relays. This is intented to stop opportunistic
  13 network scanning and subsequent discovery of private bridge relays.
  14
  15
  16 0.1 Current Implementation
  17
  18 Currently private bridges are only hidden by their obscurity. If you know
  19 a bridge ip address, the bridge can be detected trivially and added to a block
  20 list.
  21
  22 0.2 Configuring an external port knocking program to control the firewall
  23
  24 It is currently possible for bridge operators to configure a port knocking
  25 daemon that controls access to the incoming OR port. This is currently out of
  26 scope for Tor and Tor configuration. This process requires the firewall to know
  27 the current nodes in the Tor network.
  28
  29 1.0 Suggested changes
  30
  31 Private bridge operators should be able to configure a method of hiding their
  32 relay. Only authorized users should be able to communicate with the private
  33 bridge. This should be done with Tor and if possible without the help of the
  34 firewall. It should be possible for a Tor user to enter a secret key into
  35 Tor or optionally Vidalia on a per bridge basis. This secret key should be
  36 used to authenticate the bridge user to the private bridge.
  37
  38 1.x Issues with low ports and bind() for ORPort
  39
  40 Tor opens low numbered ports during startup and then drops privileges. It is
  41 no longer possible to rebind to those lower ports after they are closed.
  42
  43 1.x Issues with OS level packet filtering
  44
  45 Tor does not know about any OS level packet filtering. Currently there is no
  46 packet filters that understands the Tor network in real time.
  47
  48 1.x Possible partitioning of users by bridge operator
  49
  50 Depending on implementation, it may be possible for bridge operators to
  51 uniquely identify users. This appears to be a general bridge issue when a
  52 bridge operator uniquely deploys bridges per user.
  53
  54 2.0 Implementation ideas
  55
  56 This is a suggested set of methods for port knocking.
  57
  58 2.x Using SPA port knocking
  59
  60 Single Packet Authentication port knocking encodes all required data into a
  61 single UDP packet. Improperly formatted packets may be simply discarded.
  62 Properly formatted packets should be processed and appropriate actions taken.
  63
  64 2.x Using DNS as a transport for SPA
  65
  66 It should be possible for Tor to bind to port 53 at startup and merely drop all
  67 packets that are not valid. UDP does not require a response and invalid packets
  68 will not trigger a response from Tor. With base32 encoding it should be
  69 possible to encode SPA as valid DNS requests. This should allow use of the
  70 public DNS infrastructure for authorization requests if desired.
  71
  72 2.x Ghetto firewalling with opportunistic connection closing
  73
  74 Until a user has authenticated with Tor, Tor only has a UDP listener. This
  75 listener should never send data in response, it should only open an ORPort
  76 when a user has successfully authenticated. After a user has authenticated
  77 with Tor to open an ORPort, only users who have authenticated will be able
  78 to use it. All other users as identified by their ip address will have their
  79 connection closed before any data is sent or received. This should be
  80 accomplished with an access policy. By default, the access policy should block
  81 all access to the ORPort.
  82
  83 2.x Timing and reset of access policies
  84
  85 Access to the ORPort is sensitive. The bridge should remove any exceptions
  86 to its access policy regularly when the ORPort is unused. Valid users should
  87 reauthenticate if they do not use the ORPort within a given time frame.
  88
  89 2.x Additional considerations
  90
  91 There are many. A format of the packet and the crypto involved is a good start.