Yet another Dynamic Tunnel Configuration Prototocol

By Peter R. Tattam,  Trumpet Software International Pty Ltd.


1. Introduction

This protocol is intended to allow a user to connect to the 6bone in a
dynamic way possibly via an automatically initiated mechanism tied to the
IPv6 TCP/IP stack.  While intended for IPv6 the protocol could also be used
for IPv4 and Secure tunnels (VPNs).

2.  Protocol specifications.

The client connects to the Tunnel server via IPv4 TCP protocol on a well
known port.  I have chosen port 20200 as a temporary measure for testing.
It is a text based command/response oriented protocol. Responses to commands
always have as the first part of the response a response code.  This would
be either a +OK or -ERR as the first word of the line. All lines should use
<CR><LF> as line terminators in both directions.  Unrecognized commands
should invoke a -ERR response.  It is important to note that in this
protocol, the <empty string> is a valid command and should result in a -ERR
response.

Upon connection to the server, the first response would be

    +OK <Chap-Challenge> <comment>

e.g.

    +OK A58E729C079578962BF8E1DBB293012A Fanfare Tunnel server ready.


The chap-challenge is a randomly generated key used as a chap challenge for
authentication of a user.


The client then sends a tunnel command with the following format.

 tunnel <username> <chap-response> <tunnel-type>

e.g.
    tunnel fred 7DDBED2073AD8FA5B43E3DC4CFF62045 host

The chap response is the hexadecimal representation of
    MD5(<username>&<chap-challenge>&<password>)

where
    <username> is common to the client and server
and
    <password> is a shared secret associated with the username.
    "&" represents the string concatenation operator.

This technique ensures that the password is never sent in the clear or even
in encrypted form and offers a similar level of security to PPP CHAP
authentication.

The tunnel type is for informational purposes and can be used to convey
information to the tunnel server information which it can use in determining
an address. At present, only the "host" type is defined which means that the
tunnel may be used as a point to point connection to the 6bone, with the
client end of the tunnel representing the host's address.

In reply to the tunnel command, the host may reply one only of the
following.

    +OK <IPv4-client> <IPv4-server> [ <IPv6-client> <IPv6-server> ] {
<optional information> }

    -ERR unable to create tunnel.

    -ERR authentication failed.

e.g.
    +OK 203.5.119.43 203.5.119.212 3FFE:2804:100::6 3FFE:2804:100::5

The <IPv4-client> <IPv4-server> <IPv6-client> <IPv6-server> components are
the tunnel endpoints in the IPv4 and IPv6 domains respectively.
<IPv4-client> and <IPv4-server> would typically be the IPV4 endpoints of the
TCP session used for this protocol.  For unnumbered tunnels, the
<IPv6-client> and <IPv6-server> addresses can be omitted.  In the case of
explicit tunnel specifications, one would typically use a /126 prefix to
define the IPv6 tunnel.

Once a tunnel is established, the client may use normal tunnel protocols for
IPv6 tunnelling using the endpoints supplied by the server, typically over
IP port 41.  The tunnel will only remain active while the TCP connection to
the tunnel server is active.  It may be required to extend this protocol to
allow for persistent tunnels.  The <username> component can be used to
reference a persistent database defining the tunnels for that user.  The
protocol also allows for tunnels to be created anonymously if one so desires
by use of the "anonymous" username providing that the tunnel server permits
this.

Once a tunnel is established, it must be kept alive by regularly pinging the
tunnel server on the same
session.

The command

    ping

can be sent to which the reply will be

    +OK

can used to ping the server,

or sending an empty string as a command is sufficient if a response is not
required.

The tunnel server will timeout after a predefined number of seconds if it
has not received any command.  This should be configurable, but with a
default value of 300 seconds.  The timeout MUST be no less than 30 seconds.
A ping or <empty string> command SHOULD be sent a minimum of every 10
seconds.

To close the tunnel, the command

    QUIT

can be sent to which the reply will be

    +OK tunnel server quitting.

Any other commands are totally ignored by the tunnel server, and no response
must be sent.

Once a tunnel is set up, it is undefined whether a new tunnel may be set up
using the same connection. If the tunnel server supports this mode of
operation, any existing tunnel would be torn down before attempting to
authenticate and establish a new tunnel. Also, it is undefined as to how
many failed login attempts may be allowed within the same connection. It
would be wise to define some limit, say 3 attempts before the connection is
forcefully closed by the tunnel server.

All commands may be executed at any point, and server should be prepared for
this.

It is up to the client and the server to establish the tunnel interfaces to
the TCP/IP stack to establish, and because this is highly platform
dependent, cannot be specified in this document.

Management of tunnel user names could be implemented via the Tunnel Broker
model, however this dynamic tunnel protocol does not necessarily have to
adhere to such a system.  It might be preferable instead to use existing
authentication mechanisms that may be in place for an organization, for
example unix logins or RADIUS.

3. Conclusion

This protocol is designed to be simple and quickly implemented.  Any
extensions should take this into consideration. An attempt was also made to
build persistent tunnels that would remain after the session was closed,
however this added a significant number of complications that made the
server difficult to implement reliably in practice.


Appendix A

A typical tunnel session is shown


C: initiates connection
S: accepts connection

    S: +OK A58E729C079578962BF8E1DBB293012A Fanfare Tunnel server ready.
    C: tunnel fred 7DDBED2073AD8FA5B43E3DC4CFF62045 host
    S: +OK 203.5.119.43 203.5.119.212 3FFE:2804:100::6 3FFE:2804:100::5

    time passes...

    C: ping
    S: +OK

    time passes...

    C: ping
    S: +OK

    time passes...

    C: quit
    S: +OK

S: closes connection
C: closes connection



Appendix B

Other tunnel Types.

Some suggestions are....


a) explicitly unnumbered tunnels

    tunnel <username> <chap-response> tunnelonly

to which the response would be

    +OK <IPv4-client> <IPv4-server>


b) a tunnel network

    tunnel <username> <chap-response> network

to which the response would be

    +OK <IPv4-client> <IPv4-server> [ <IPv6-client> <IPv6-server> ]
<IPv6-network>/<prefixlen>

Where <IPv6-network>/<prefixlen> which be a valid routable <IPv6 network
address>.  It would be the responsibility of the tunnel client to
redistribute this network address to the relevant local network as
necessary.

