QuickTunTCP: Difference between revisions

From Qontrol.nl Wiki
Jump to navigation Jump to search
(Created page with "== QuickTun TCP mode == This page contains a draft for the protocol to be used in a client/server version of QuickTun using TCP. == Protocol == <pre> TCP session Client: 32 byt...")
 
mNo edit summary
Line 1: Line 1:
== QuickTun TCP mode ==
== QuickTun TCP mode ==
This page contains a draft for the protocol to be used in a client/server version of QuickTun using TCP.
This page contains a draft for the protocol to be used in a client/server version of QuickTun using TCP.
'''THIS DOCUMENT IS OBSOLETE! A newer version is available here: [[QuickTunTcp]]'''


== Protocol ==
== Protocol ==

Revision as of 15:22, 21 August 2014

QuickTun TCP mode

This page contains a draft for the protocol to be used in a client/server version of QuickTun using TCP.

THIS DOCUMENT IS OBSOLETE! A newer version is available here: QuickTunTcp

Protocol

TCP session

Client: 32 byte public key or all zero key
Server: 32 byte public key or all zero key
Note: all zero key is used in case the remote side is supposed to know the key, and it is undesirable to send the real public key. The all zero public key is hereby excluded from the valid public keys.

If only the client public key is all zero:
	Client: encrypted packet containing 15 random bytes to be used as the first part of the nonce, encrypted using an all zero nonce. The encrypted packet length is then 15+16=31 bytes.
	The server can try to decrypt the message using all (remote) public keys it knows to find out which key is valid.
Otherwise:
	Server: encrypted packet containing 15 random bytes to be used as the first part of the nonce, encrypted using an all zero nonce. The encrypted packet length is then 15+16=31 bytes.
	Note that both sides providing an all zero key is only valid in a peer to peer configuration, when at least the server knows the client's public key.

From here on all packets are framed using a 16 bit big endian length header.

From here on the cryptographic nonce is formed as follows: <1byte:server=0/client=1><15byte:negotiatednonce><8byte:64bitcounter>
The first byte of the nonce depends on which side encrypts the packet (tcp server -> 0, tcp client -> 1); the next 15 bytes are given by the the previous packet, the last 8 bytes should contain a 64 bit big endian integer which starts at 0 and is incremented by 1 after each packet.

The plain text part of each message consists of a one byte header (<1byte:commandidentifier>) followed by the actual data.

Command identifiers:
	0: tunneled data
		IP or ethernet data, as negotiated/configured
	1: user/password authentication (client->server)
		<1byte:length><Nbyte:username><1byte:length><Nbyte:password>
	1: user/password data confirmation or rejection (server->client)
		<1byte:ok=0/undefinederror=1/errors=other>
	2: tunnel configuration (server->client)
		<1byte:configurationcontext(0=tunneltype,1=ethernet,2=IPv4,3=IPv6>
		0: tunnel type
			<1byte:tuntype(1=IP,2=ethernet,3=obsolete_IP_USE_PI)>
		1: ethernet
			<6byte:macaddress>
		2: ipv4
			<4byte:ipv4address><1byte:prefixlength><4byte:dnsserver><1byte:numroutes>[<4byte:destnet><1byte:prefixlength><4byte:gateway>]
			Note: if the ipv4address or dnsserver is 0.0.0.0, it is not set and should not be used
		3: ipv6
			<16byte:ipv6address><1byte:prefixlength><16byte:dnsserver><1byte:numroutes>[<16byte:destnet><1byte:prefixlength><16byte:gateway>]
	3: echo packet (both directions, does not expect an answer)
			Note: if the ipv6address or dnsserver is ::, it is not set and should not be used

	4: Out-of-band BGP?
		<1byte:addressfamily(1=ethernet,2=ipv4,3=ipv6)><1byte:event(1=add,2=delete)><4byte:destnet><1byte:prefixlength><4byte:gateway><2byte:pathlength>[<2byte:asnumber>]