
This document is mostly relevant for folks who are using packet filters
in conjunction with ftp-gw, and, have Tor's PASV patch as well as the
data-port patch installed.

When ftp-gw is actively proxy-ing, it acts like an ftp server on one
side, and an ftp client on the other side.  The proxy may choose to use
PORT or PASV independently of what the real client host chooses. 

Let's look at some variations:

      1)      client --PORT-> ftp-gw --PORT-> remote
                     <-data--        <-data--

      2)      client --PORT-> ftp-gw --PASV-> remote
                     <-data--        --data->

      3)      client --PASV-> ftp-gw --PORT-> remote
                     --data->        <-data--

      4)      client --PASV-> ftp-gw --PASV-> remote
                     --data->        --data->

Scenarios 1 and 3 require that new inbound connections on ports 1024+ be
allowed from the outside (remote side) of the proxy by the packet
filters.  Because this is undesirable, we can configure the proxy to
always use PASV:

  ftp-gw: pasv true

Now scenarios 2 and 4 are all that remain.  Scenario 4 requires that new
inbound connections on ports 1024+ be allowed from the inside (client
side) of the proxy by the packet filters.  Let's send a "502 Command not
implemented" to these clients:

  ftp-gw: pasv true -portonly

Most clients default to PORT.  Any client that has been configured to
use PASV will most likely fall back to PORT when it gets the 502.  Now
scenario 2 is our last remaining scenario.

The good news about scenario 2 is that we can deny any incoming packet
that does not have the ACK bit toggled and is coming in on a high port
number.  The bad news is that there are lots of high port numbers.
Let's narrow down the possibilities:

  ftp-gw: data-port 62345

The proxy is initiating the data channel connection (sending that first
SYN packet); it is sending to a destination port that was sent to it
over the control channel.  This is a kinda-random high port on the
destination host.  The port number is sufficiently unique that the proxy
is free to choose a source port that is always the same for all data
connections without having to worry about "duplicate bind" issues.

We can now use a quite restrictive filtering scheme.  We only allow
inbound packets to one high port (62345) and then only if the ACK bit is
toggled.  This rule is good for all interfaces.

CAVEAT:  We're in trouble if the remote 502's us; we don't fall back... :^)

HTTP-GW:  The ftp proxy capabilities of http-gw are not needed if ftp-gw
          has the tranparency patch.

SEE ALSO:

  http://www.interhack.net/pubs/fwfaq/#head_howftp
  http://www.cis.ohio-state.edu/htbin/rfc/rfc959.html
  http://www.cis.ohio-state.edu/htbin/rfc/rfc1123.html
  http://www.cis.ohio-state.edu/htbin/rfc/rfc1579.html

