[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httptunnel
Subject:    Suggestion on a future protocol version
From:       "Ben Efros" <ben () efros ! com>
Date:       2001-03-13 3:18:10
[Download RAW message or body]

Just a draft idea here... If anyone begins work on a new http tunnel, I
think the following may help make a flexible server design:

The new protocol suggestions start with three different layers of
connection:
          1)  Incoming Connection Management - Listens on port xxx for
connections.  When incoming connections are made, verifies that the request
is HTTP and appears to be a valid HTTP tunnel message.  A portion of this
layer should be considered the "virtual connection management" which
combines one or more proxy connections as if they were one, sending response
data over what it believes as the best route through Proxy connections if
multiple connections exist.
                * This layer should bypass the authentication layer, if the
connection is already established.

           2) Authentication - Handles all new connections requesting to
send outbound traffic.  This layer should reject any connection without
valid user authentication or access rights (from the access control list).
This binary could verify from /etc/passwd, a custom passwd file, or any
other authentication method.  The authentication layer should _only_ be
called when new, unknown connections are established with httptund and they
appear to contain HTTP tunnel data.
        3) Outgoing Connection Management - Reads "HTTP Tunnel Header" and
determines what TCP connection to send data through or establishes a new TCP
connection if needed.

I recommend that the layers be divided into two separate binaries:

            httptund - Does connection management
            httptunauth - Does authentication

            Environment variables httptunauth should have are:
                        VIRTUAL_TUNNEL_ID - The identification number which
uniquely identifies the "virtual" connection
                        USERNAME
                        PASSWORD
                        DEST_ IP - final destination address
                        DEST_PORT
                        SOURCE_IP - the client running "htc" . if the http
proxy forwards such information about the client, should not be required
                        SOURCE_PORT
                        PROXY - list containing the proxies that may be
involved with the connection, separated by "::" .  example:
"proxy.company.com:80::proxy2.company.com:3128"
                        CONTENT_TYPE - the http content-type that the web
proxy thinks it is passing on.  (The ability to vary content types is
sometimes critical to bypassing censorware)

The ability for the daemon to handle multiple [virtual] tunnels is
important.  Each virtual tunnel is a combination of actual HTTP tunnels.
When one tunnel disconnects, data can still be sent over another connected
tunnel or the tunnel with the least "path cost" (either specified or
determined by an http-based "ping") can be selected.  I have noticed that
the reconnection process in the current httptunnel can take a while, this
would eliminate that problem while at the same time possibly increasing the
bandwidth.

It may be a good idea to send packets along the connections, each packet
containing a header which says what its order is... in case the packet sent
after it (possibly from another proxy server) arrives at the httptund first.
If a packet appears "lost" then httptund sends a notification saying "lost
packet" and asks for a resend.  When httptund starts receiving a large
number of packets for the same VIRTUAL_TUNNEL_ID in an out-of-order fashion
it may need to send a "slow down" message about one of the links, meaning
that one path through one of the proxy servers is taking excessively long.

I don't know if I will ever get around to implementing something like this,
but I hope any future developers of a new http tunnel will.

-- Ben





_______________________________________________
http://mailman.nocrew.org/cgi-bin/mailman/listinfo/nocrew-httptunnel

[prev in list] [next in list] [prev in thread] [next in thread]