From f38b9f67f87c364c50fd21d48aa85f946675b4e2 Mon Sep 17 00:00:00 2001 From: Guus Sliepen Date: Thu, 17 Apr 2014 15:38:08 +0200 Subject: [PATCH] Remove outdated or not-applicable documents. --- doc/CONNECTIVITY | 43 -------------- doc/NETWORKING | 81 -------------------------- doc/PROTOCOL | 148 ----------------------------------------------- doc/SECURITY2 | 121 -------------------------------------- 4 files changed, 393 deletions(-) delete mode 100644 doc/CONNECTIVITY delete mode 100644 doc/NETWORKING delete mode 100644 doc/PROTOCOL delete mode 100644 doc/SECURITY2 diff --git a/doc/CONNECTIVITY b/doc/CONNECTIVITY deleted file mode 100644 index 05a9eaf3..00000000 --- a/doc/CONNECTIVITY +++ /dev/null @@ -1,43 +0,0 @@ -This document describes how nodes in a VPN find and connect to eachother and -maintain a stable network. - - Copyright 2001-2006 Guus Sliepen - - 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. diff --git a/doc/NETWORKING b/doc/NETWORKING deleted file mode 100644 index eb4f6bc6..00000000 --- a/doc/NETWORKING +++ /dev/null @@ -1,81 +0,0 @@ -This is the network infrastructure documentation for tinc, a Virtual Private -Network daemon. - - Copyright 2001-2006 Guus Sliepen - - 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(). diff --git a/doc/PROTOCOL b/doc/PROTOCOL deleted file mode 100644 index 3e2915bd..00000000 --- a/doc/PROTOCOL +++ /dev/null @@ -1,148 +0,0 @@ -This is the protocol documentation for tinc, a Virtual Private Network daemon. - - Copyright 2000-2006 Guus Sliepen , - 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. diff --git a/doc/SECURITY2 b/doc/SECURITY2 deleted file mode 100644 index 56db6b60..00000000 --- a/doc/SECURITY2 +++ /dev/null @@ -1,121 +0,0 @@ -This is the security documentation for tinc, a Virtual Private Network daemon. - - Copyright 2001-2006 Guus Sliepen , - 2001-2006 Wessel Dankers - - 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 - -server - -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? -- 2.39.5