+++ /dev/null
-This document describes how nodes in a VPN find and connect to eachother and
-maintain a stable network.
-
- Copyright 2001-2006 Guus Sliepen <guus@meshlink.io>
-
- 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.
-
- 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.
-
-1. Synchronisation
-==================
-
-Each tinc daemon has zero or more connections to other tinc daemons. It will
-try to keep its own information synchronised with the other tinc daemons. If
-one of its peers sends information, the tinc daemon will check if it is new
-information. If so, it will update its own information and forward the new
-information to all the other peers.
-
-This scheme will make sure that after a short amount of time all tinc daemons
-share the same information. It will also almost completely prevent information
-from looping, because "new" information that is already known is ignored and
-not forwarded any further. However, since information can also be deleted
-there's the possibility of a looping sequence of add/delete messages. This is
-resolved by additionaly adding a unique identifier to each broadcasted message.
-Messages are dropped if the same message with that identifier has already been
-seen.
-
-2. Routing
-==========
-
-Every node tells its peers to which other peers it is connected. This way
-every node will eventually know every connection every node has on the VPN.
-Each node will use graph algorithms to determine if other nodes are reachable or not and
-what the best route is to other nodes.
-
-Because all nodes share the same information, using a deterministic algorithm
-each node will calculate the same minimum spanning tree for the entire VPN.
-The MST will be used to send broadcast VPN packets.
+++ /dev/null
-This is the network infrastructure documentation for tinc, a Virtual Private
-Network daemon.
-
- Copyright 2001-2006 Guus Sliepen <guus@meshlink.io>
-
- 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.
-
- 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.
-
-1. Packet flow
-==============
-
-There are two directions for packets. There are packets received from the tap
-device that have to be sent out to other tinc daemon, and there are packets
-that are received from other tinc daemons which have to be send to the tap
-device. The first direction will be called the outgoing direction, while the
-latter will be called the incoming direction.
-
-1.1 Outgoing flow
------------------
-
- handle_tap_input()
- |
- |
- V
- route_outgoing()
- |
- |
- V
- send_packet() ----
- / \ / \
- / \ | queue
- V V V /
-send_tcppacket() send_udppacket()--
-
-Packets are read from the tap device by handle_tap_input(). The packets will be
-marked as coming from ourself, and are then handled by route_outgoing(). This
-function will determine the destination tinc daemon this packet has to be sent
-to, and in the future it may also determine if this packet has to be broadcast
-or multicast. route_outgoing() will call send_packet() (in case of
-broad/multicast several times). send_packet() will check the destination
-connection_t entry to see if it is a valid destination, and whether it has to
-be sent via TCP or UDP. It will then either call send_tcppacket() or
-send_udppacket(). Since a different key is used for UDP packets, which might
-not be available at that time, send_udppacket() might put the packet in a queue
-and send a REQ_KEY to the destination tinc daemon. If the key has been retrieved,
-the packet will be fed to send_udppacket() again.
-
-1.2 Incoming flow
------------------
-
- handle_vpn_input()
- |
- |
- V
-tcppacket_h() receive_udppacket()
- \ /
- \ /
- V V
- receive_packet()
- |
- |
- V
- route_incoming()
- |
- |
- V
- accept_packet()
-
-Packets from other tinc daemons can be received by tcppacket_h(), for TCP
-packets, and receive_udppacket() via handle_vpn_input() for UDP packets.
-receive_packet() actually does not have to do much, except logging and calling
-route_incoming(), but it's there for symmetry with the scheme for the outgoing
-flow. route_incoming() will change the MAC header of the packet if necessary to
-let the kernel accept the packet after it has been sent to the tap device by
-accept_packet().
+++ /dev/null
-This is the protocol documentation for tinc, a Virtual Private Network daemon.
-
- Copyright 2000-2006 Guus Sliepen <guus@meshlink.io>,
- 2000-2005 Ivo Timmmermans
-
- 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.
-
- 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.
-
-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 or the universal TUN/TAP device that
-can be found in various UNIX flavours.
-
-2. Packet protocol
-------------------
-
-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, 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 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
-----------------
-
-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.
-
-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
-synchronised.
-
-daemon message
---------------------------------------------------------------------------
-origin ADD_EDGE node1 node2 21.32.43.54 655 222 0
- | | | | | +-> options
- | | | | +----> weight
- | | | +--------> UDP port of node2
- | | +----------------> real address of node2
- | +-------------------------> name of destination node
- +-------------------------------> name of source node
-
-origin ADD_SUBNET node 192.168.1.0/24
- | | +--> prefixlength
- | +--------> network address
- +------------------> owner of this subnet
---------------------------------------------------------------------------
-
-The ADD_EDGE messages are to inform other tinc daemons that a connection between
-two nodes exist. The address of the destination node is available so that
-VPN packets can be sent directly to that node.
-
-The ADD_SUBNET messages inform other tinc daemons that certain subnets belong
-to certain nodes. tinc will use it to determine to which node a VPN packet has
-to be sent.
-
-message
-------------------------------------------------------------------
-DEL_EDGE node1 node2
- | +----> name of destination node
- +----------> name of source node
-
-DEL_SUBNET node 192.168.1.0/24
- | | +--> prefixlength
- | +--------> network address
- +------------------> owner of this subnet
-------------------------------------------------------------------
-
-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.
-
-message
-------------------------------------------------------------------
-REQ_KEY origin destination
- | +--> name of the tinc daemon it wants the key from
- +----------> name of the daemon that wants the key
-
-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
-
-KEY_CHANGED origin
- +--> daemon that has changed it's packet key
---------------------------------------------------------------------------
-
-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
-chances are that not every tinc daemon will ever send a packet to every
-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 its copy back to the requestor.
-
-daemon message
---------------------------------------------------------------------------
-origin PING
-dest. PONG
---------------------------------------------------------------------------
-
-There is also a mechanism to check if hosts are still alive. Since network
-failures or a crash can cause a daemon to be killed without properly
-shutting down the TCP connection, this is necessary to keep an up to date
-connection list. Pings are sent at regular intervals, except when there
-is also some other traffic. A little bit of salt (random data) is added
-with each PING and PONG message, to make sure that long sequences of PING/PONG
-messages without any other traffic won't result in known plaintext.
-
-This basically covers everything that is sent over the meta connection by
-tinc.
+++ /dev/null
-This is the security documentation for tinc, a Virtual Private Network daemon.
-
- Copyright 2001-2006 Guus Sliepen <guus@meshlink.io>,
- 2001-2006 Wessel Dankers <wsl@tinc-vpn.org>
-
- 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.
-
- 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.
-
-Proposed new authentication scheme
-----------------------------------
-
-A new scheme for authentication in tinc has been devised, which offers some
-improvements over the protocol used in 1.0pre2 and 1.0pre3. Explanation is
-below.
-
-daemon message
---------------------------------------------------------------------------
-client <attempts connection>
-
-server <accepts connection>
-
-client ID client 12
- | +---> version
- +-------> name of tinc daemon
-
-server ID server 12
- | +---> version
- +-------> name of tinc daemon
-
-client META_KEY 5f0823a93e35b69e...7086ec7866ce582b
- \_________________________________/
- +-> RSAKEYLEN bits totally random string S1,
- encrypted with server's public RSA key
-
-server META_KEY 6ab9c1640388f8f0...45d1a07f8a672630
- \_________________________________/
- +-> RSAKEYLEN bits totally random string S2,
- encrypted with client's public RSA key
-
-From now on:
- - the client will symmetrically encrypt outgoing traffic using S1
- - the server will symmetrically encrypt outgoing traffic using S2
-
-client CHALLENGE da02add1817c1920989ba6ae2a49cecbda0
- \_________________________________/
- +-> CHALLEN bits totally random string H1
-
-server CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d57f
- \_________________________________/
- +-> CHALLEN bits totally random string H2
-
-client CHAL_REPLY 816a86
- +-> 160 bits SHA1 of H2
-
-server CHAL_REPLY 928ffe
- +-> 160 bits SHA1 of H1
-
-After the correct challenge replies are recieved, both ends have proved
-their identity. Further information is exchanged.
-
-client ACK 655 123 0
- | | +-> options
- | +----> estimated weight
- +--------> listening port of client
-
-server ACK 655 321 0
- | | +-> options
- | +----> estimated weight
- +--------> listening port of server
---------------------------------------------------------------------------
-
-This new scheme has several improvements, both in efficiency and security.
-
-First of all, the server sends exactly the same kind of messages over the wire
-as the client. The previous versions of tinc first authenticated the client,
-and then the server. This scheme even allows both sides to send their messages
-simultaneously, there is no need to wait for the other to send something first.
-This means that any calculations that need to be done upon sending or receiving
-a message can also be done in parallel. This is especially important when doing
-RSA encryption/decryption. Given that these calculations are the main part of
-the CPU time spent for the authentication, speed is improved by a factor 2.
-
-Second, only one RSA encrypted message is sent instead of two. This reduces the
-amount of information attackers can see (and thus use for a crypto attack). It
-also improves speed by a factor two, making the total speedup a factor 4.
-
-Third, and most important:
-
-The symmetric cipher keys are exchanged first, the challenge is done
-afterwards. In the previous authentication scheme, because a man-in-the-middle
-could pass the challenge/chal_reply phase (by just copying the messages between
-the two real tinc daemons), but no information was exchanged that was really
-needed to read the rest of the messages, the challenge/chal_reply phase was of
-no real use. The man-in-the-middle was only stopped by the fact that only after
-the ACK messages were encrypted with the symmetric cipher. Potentially, it
-could even send it's own symmetric key to the server (if it knew the server's
-public key) and read some of the metadata the server would send it (it was
-impossible for the mitm to read actual network packets though). The new scheme
-however prevents this.
-
-This new scheme makes sure that first of all, symmetric keys are exchanged. The
-rest of the messages are then encrypted with the symmetric cipher. Then, each
-side can only read received messages if they have their private key. The
-challenge is there to let the other side know that the private key is really
-known, because a challenge reply can only be sent back if the challenge is
-decrypted correctly, and that can only be done with knowledge of the private
-key.
-
-Fourth: the first thing that is send via the symmetric cipher encrypted
-connection is a totally random string, so that there is no known plaintext (for
-an attacker) in the beginning of the encrypted stream.
-
-Some things to be discussed:
-
- - What should CHALLEN be? Same as RSAKEYLEN? 256 bits? More/less?
projects / meshlink / commitdiff