Modes

There are these modes:

• Direct: from one end-point to another, directly, both ways. Anything from A is sent to B, anything from B is sent to A. All else is dropped.
• Proxy-to-server: all traffic into local end-point X:x is directed to end-point B:b Replies from B:b are channelled back to original sender, appearing to come from X:x.
  Server-proxy: Reverse of above. Remote traffic arriving into remote Y:y is directed to local end-point A:a. Reverse of above. Replies from Alice to X:x are channelled back to original sender, appearing to arrive from Y:y.
• Stream: All traffic arriving at a node is pused through to a single server at the other node. One way. (Two modes...)
• Router: Packets arriving from any location to A are transported and sent out from B to their targets. Requires eventual target for packet to be carried along with packet's local target. (Requires forgery of IP packet or higher protocol?)

Conventions

Use upper case letters as IP# and lowercase as port numbers on that IP#. A and B are customer sockets. X and Y are the SDT nodes for customers to talk to. P and Q are the internal encrypted sockets.

    Alice         Local             Remote        Bob
    A:a --------- X:x . . . . . . . Y:y --------- B:b

                  P:p ------------- Q:q

P and Q aren't needed for this discussion.

Assumptions

• Let's ignore interfaces for now, but the whole interface needs to consider especially named sockets.
• Assume only one physical tunnel from X to Y.
• Assume only one Encryption pair to cover all.
• Channels therefore need to exist inside.
• Assume a fixed limit on channels. (This is simply C static / stack programming limits.)

To cover all of the eventualities, the packets may need to carry with them:

Modes

Direct

From one end-point to another, directly. Anything from A:a is sent to B:b, anything from B:b is sent to A:a. All else is dropped.

For one virtual tunnel per process, no additional info past set-up is required. If there are multiple virtual tunnels then there is a need for a channel. Each sent packet needs to identify its end-points tuple as a channel.

Server mode

Mirror imaged modes

There are two versions, but they are mirror images.

Proxy-to-server: Local is the Proxy, remote is server. From local node to remote node, all traffic into listener X:x is directed to server B:b. Replies from B are channelled back to original sender, appearing to come from A.

Server-proxy: remote traffic arriving at B is directed to local server, via local node A. Reverse of above. Replies from server to A are channelled back to original sender, appearing to arrive from B.

Design

Proxy node receives a packet from P:p, this tuple needs to be recorded and channelled. The packet is sent off to server node with a channel indicator C.

On seeing Channel C, server node creates a new socket, and sends to the server using that socket. Replies back to that same socket indicate channel C, which is recorded back to the proxy node.

Both proxy and server nodes then need to maintain channel lists. What is not necessary -- apparently -- is any pre-ordained setup (other than potential channel limit), nor is there any need for the details of the channel to be exchanged.

Stream

All traffic arriving at a node is pused through to a single server at the other node. One way.

This is useful for logging systems where the task is to suck messages off the machine for archiving elsewhere.

This may be a subset of the server mode. Likewise there are two mirrored images, local as proxy and remote as proxy.

The difference with the server mode is that without the need for replies, there is no need for multiple sockets and channelling. Resources are therefore smaller.

Router

Packets arriving from any location to A are transported and sent out from B to their targets. Outgoing packets need to carry their eventual target, replies could just be channelised according to local reply.

If dealing in IP packets, this requires forgery of IP packet at local node, as replies need to be returned as if from the target. But, as there is already an expectation that the local node has captured the routed traffic to non-local addresses, this would seem to be plausible.

It seems that this mode is somewhat hypothetical for now. Also, check out the SSH VPN feature; this may make it clearer.