This is the protocol documentation for tinc, a Virtual Private Network daemon.
- Copyright 2000 Guus Sliepen <guus@sliepen.warande.net>
+ Copyright 2000 Guus Sliepen <guus@sliepen.warande.net>,
+ 2000 Ivo Timmmermans <itimmermans@bigfoot.com>
Permission is granted to make and distribute verbatim copies of
- this documentation provided the copyright notice and this permission
- notice are preserved on all copies.
+ this documentation provided the copyright notice and this
+ permission notice are preserved on all copies.
- Permission is granted to copy and distribute modified versions
- of this documentation under the conditions for verbatim copying, provided
- that the entire resulting derived work is distributed under
- the terms of a permission notice identical to this one.
+ Permission is granted to copy and distribute modified versions of
+ this documentation under the conditions for verbatim copying,
+ provided that the entire resulting derived work is distributed
+ under the terms of a permission notice identical to this one.
- $Id: PROTOCOL,v 1.1.2.2 2000/07/01 14:32:24 guus Exp $
+ $Id: PROTOCOL,v 1.1.2.3 2000/09/10 15:07:41 zarq Exp $
-1. Protocols used in tinc
+1. Protocols used in tinc
-------------------------
-Tinc uses several protocols to function correctly. To enter the network of tinc
-daemons that make up the virtual private network, tinc makes TCP connections to
-other tinc daemons. It uses the "meta protocol" for these connections. To
-exchange packets on the virtual network, UDP connections are made and the
-"packet protocol" is used. Tinc also needs to exchange network packets with the
-kernel. This is done using the ethertap device in Linux. Also planned is a
-generic PPP interface, because it is supported on virtually all UNIX flavours.
-The protocols for those interfaces will not be described in this document.
+tinc uses several protocols to function correctly. To enter the
+network of tinc daemons that make up the virtual private network, tinc
+makes TCP connections to other tinc daemons. It uses the "meta
+protocol" for these connections. To exchange packets on the virtual
+network, UDP connections are made and the "packet protocol" is used.
+Tinc also needs to exchange network packets with the kernel. This is
+done using the ethertap device in Linux. Also planned is a generic
+PPP interface, because it is supported on virtually all UNIX flavours.
+The protocols for those interfaces will not be described in this
+document.
-2. Packet protocol
+2. Packet protocol
------------------
-See net.h for now.
+Normal packets are sent without any state information, so the layout
+is pretty basic. An exception to this are the connections which only
+use TCP (configured with the directive `TCPonly=yes'). An explanation
+of this type of packet is given in the next chapter, when we explain
+the meta protocol.
-3. Meta protocol
+A data packet can only be sent if the encryption key is known to both
+parties, and the connection is activated. Normally, tinc opens a UDP
+connection when it receives an acknowledgement that the newly set up
+connection is properly initiated, and has been verified.
+
+ 0 1 2 3
+| SOURCE IP |
+| SEQUENCE ID |
+| LEN | DATA : \
+: DATA . } encrypted
+. : /
+ .
+
+
+3. Meta protocol
----------------
-The meta protocol is used to tie all tinc daemons together, and exchange
-information about which tinc daemon serves which virtual subnet.
-
-The meta protocol consists of requests that can be sent to the other side. Each
-request has a unique number and several parameters. All requests are represented
-in the standard ASCII character set. It is possible to use tools such as telnet
-or netcat to connect to a tinc daemon and to read and write requests by hand,
-provided that one understands the numeric codes sent.
-
-When tinc daemons connect to each other, they will have to authenticate each
-other first. This is done by exchanging BASIC_INFO, PASSPHRASE, PUBLIC_KEY and
-ACK requests. BASIC_INFO requests contain the virtual address and netmask of the
-tinc daemon, protocol version, port number and flags. This identifies that tinc
-daemon, though it still has to be verified. To that end, passphrases and public
-keys are exchanged. The passphrases are known at both ends, but they are
-encrypted with the public key before transmission. This way, nobody that sniffs
-the network can see what the passphrase actually was, and at the same time this
-ensures that the other host really knows the secret key that belongs to the
-public key it sends. If both hosts are satisfied, the connection is activated,
-the contents of each other's connection lists are exchanged and other requests
-may be sent. The following diagram shows how authentication is done:
+The meta protocol is used to tie all tinc daemons together, and
+exchange information about which tinc daemon serves which virtual
+subnet.
+
+The meta protocol consists of requests that can be sent to the other
+side. Each request has a unique number and several parameters. All
+requests are represented in the standard ASCII character set. It is
+possible to use tools such as telnet or netcat to connect to a tinc
+daemon and to read and write requests by hand, provided that one
+understands the numeric codes sent.
+
+When tinc daemons connect to each other, they will have to
+authenticate each other first. This is done by exchanging BASIC_INFO,
+PASSPHRASE, PUBLIC_KEY and ACK requests. BASIC_INFO requests contain
+the virtual address and netmask of the tinc daemon, protocol version,
+port number and flags. This identifies that tinc daemon, though it
+still has to be verified. To that end, passphrases and public keys are
+exchanged. The passphrases are known at both ends, but they are
+encrypted with the public key before transmission. This way, nobody
+that sniffs the network can see what the passphrase actually was, and
+at the same time this ensures that the other host really knows the
+secret key that belongs to the public key it sends. If both hosts are
+satisfied, the connection is activated, the contents of each other's
+connection lists are exchanged and other requests may be sent. The
+following diagram shows how authentication is done:
Client Server
----------------------------------------------------------------
-Connects to server:
- Accepts connection.
- Sends BASIC_INFO:
-Verifies BASIC_INFO.
-If server is already in
-connection list, abort.
-Else sends his own BASIC_INFO:
- Verifies BASIC_INFO.
- If client is alread in
- connection list, remove
- old entry.
- Sends PASSPHRASE:
-Receives and stores PASSPHRASE.
-Sends his own PASSPHRASE:
- Receives and stores PASSPHRASE.
- Sends PUBLIC_KEY:
-Verifies PUBLIC key and stored
-PASSPHRASE. If wrong, abort.
-Else sends his own PUBLIC_KEY:
- Verifies PUBLIC key and stored
- PASSPHRASE. If wrong, abort.
- Else activates connection and
- sends ACK and ADD_HOSTs for all
- known hosts.
-Receives ACK and activates
-connection.
-Sends ADD_HOSTs for all known
-hosts.
+
+
----------------------------------------------------------------
-The client must never make a connection to a server that is already in it's
-connection list. Not only would it corrupt the connection list, but it would
-also violate the tree property. The meta connections must always be so that
-there are no loops. This is very important, because certain requests are
-broadcast over the entire network of tinc daemons. If there were loops, packets
-would be sent infinitely.
+The client must never make a connection to a server that is already in
+it's connection list. Not only would it corrupt the connection list,
+but it would also violate the tree property. The meta connections must
+always be so that there are no loops. This is very important, because
+certain requests are broadcast over the entire network of tinc
+daemons. If there were loops in the network topology, some packets
+would be forwarded in a ring until the end of times (or until the ring
+breaks, which probably happens before time ends).
projects / meshlink / commitdiff