Dynamic Tunnel Control Protocol

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.