QuickTunTCP: Difference between revisions
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 14: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>]