This is the protocol documentation for tinc, a Virtual Private Network daemon.
- Copyright 2000,2001 Guus Sliepen <guus@sliepen.warande.net>,
- 2000,2001 Ivo Timmmermans <itimmermans@bigfoot.com>
+ Copyright 2000-2002 Guus Sliepen <guus@sliepen.warande.net>,
+ 2000-2002 Ivo Timmmermans <itimmermans@bigfoot.com>
Permission is granted to make and distribute verbatim copies of
this documentation provided the copyright notice and this
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.4 2001/01/07 17:08:02 guus Exp $
+ $Id: PROTOCOL,v 1.1.2.5 2002/02/10 21:57:51 guus Exp $
1. Protocols used in tinc
Normal packets are sent without any state information, so the layout
is pretty basic.
-A data packet can only be sent if the encryption key is known to both
-parties, and the connection is activated. If the encryption key is not
-known, a request is sent to the destination using the meta connection
-to retreive it.
+A data packet can only be sent if the encryption key, cipher and digest are
+known to both parties, and the connection is activated. If the encryption key
+is not known, a request is sent to the destination using the meta connection to
+retreive it.
- 0 1 2 3
-| LEN | DATA : \
-: DATA . } encrypted
-. : /
- .
+0 1 2 3 4 5 6 7 ... 97 98 99 100
+| seqno | data | MAC |
+\____________________________________/\_______________/
+ | |
+ encrypted using symmetric cipher digest
+The sequence number prevents replay attacks, the message authentication code
+prevents altered packets from being accepted.
3. Meta protocol
----------------
daemon and to read and write requests by hand, provided that one
understands the numeric codes sent.
-The authentication scheme is described in the SECURITY file. After a
+The authentication scheme is described in the SECURITY2 file. After a
succesful authentication, the server and the client will exchange all the
information about other tinc daemons and subnets they know of, so that both
sides (and all the other tinc daemons behind them) have their information
daemon message
--------------------------------------------------------------------------
-origin ADD_HOST daemon a329e18c:655 0
- | | +--> options
- | +---------> real address:port
- +-------------------> name of new tinc daemon
-origin ADD_SUBNET daemon 1,0a010100/ffffff00
- | | | +--> netmask
- | | +----------> vpn IPv4 network address
- | +----------------> subnet type (1=IPv4)
- +--------------------> owner of this subnet
+origin ADD_EDGE node1 12.23.34.45 655 node2 21.32.43.54 655 222 0
+ | | | \___________________/ | +-> options
+ | | | | +----> weight
+ | | | +----------------> see below
+ | | +--> UDP port
+ | +----------> real address
+ +------------------> name of node on one side of the edge
+
+origin ADD_SUBNET node 192.168.1.0/24
+ | | +--> masklength
+ | +--------> IPv4 network address
+ +------------------> owner of this subnet
--------------------------------------------------------------------------
-In case daemons leave the VPN, DEL_HOST and DEL_SUBNET messages with exactly
-the same syntax are sent to inform the other daemons of the departure.
+In case a connection between two daemons is closed or broken, DEL_EDGE messages
+are sent to inform the other daemons of that fact. Each daemon will calculate a
+new route to the the daemons, or mark them unreachable if there isn't any.
The keys used to encrypt VPN packets are not sent out directly. This is
because it would generate a lot of traffic on VPNs with many daemons, and
other daemon. Instead, if a daemon needs a key it sends a request for it
via the meta connection of the nearest hop in the direction of the
destination. If any hop on the way has already learned the key, it will
-act as a proxy and forward it's copy back to the requestor.
+act as a proxy and forward its copy back to the requestor.
daemon message
--------------------------------------------------------------------------
daemon REQ_KEY origin destination
| +--> name of the tinc daemon it wants the key from
+----------> name of the daemon that wants the key
-daemon ANS_KEY origin destination e4ae0b0a82d6e0078179b5290c62c7d0
- | | \______________________________/
- | | +--> 128 bits key
+
+daemon ANS_KEY origin destination 4ae0b0a82d6e0078 91 64 4
+ | | \______________/ | | +--> MAC length
+ | | | | +-----> digest algorithm
+ | | | +--------> cipher algorithm
+ | | +--> 128 bits key
| +--> name of the daemon that wants the key
+----------> name of the daemon that uses this key
+
daemon KEY_CHANGED origin
+--> daemon that has changed it's packet key
--------------------------------------------------------------------------
projects / oweals / tinc.git / blobdiff