tor-parallel-relay-conn/doc/spec/proposals/ideas/xxx-port-knocking.txt

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 to authenticate the bridge user to the private bridge.

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 Ghetto firewalling with opportunistic connection closing

Until a user has authenticated with Tor, Tor only has a UDP listener. This
listener should never send data in response, it should only open an ORPort
when a user has successfully authenticated. After a user has authenticated
with Tor to open an ORPort, only users who have authenticated will be able
to use it. All other users as identified by their ip address will have their
connection closed before any data is sent or received. This should be
accomplished with an access policy. By default, the access policy should block
all access to the ORPort.

2.x Timing and reset of access policies

Access to the ORPort is sensitive. The bridge should remove any exceptions
to its access policy regularly when the ORPort is unused. Valid users should
reauthenticate if they do not use the ORPort within a given time frame.

2.x Additional considerations

There are many. A format of the packet and the crypto involved is a good start.