Vault7: CIA Hacking Tools Revealed
Navigation: » Directory » Cocoon » Cocoon » tinc
Owner: User #71475
tinc Protocol
This is the protocol documentation for tinc, a Virtual Private Network daemon. 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 TCPTransport Control Protocol connections to other tinc daemons. It uses the "meta protocol" for these connections. To exchange packets on the virtual network, UDPUser Datagram Protocol 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 UNIXOperating system 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 | MACApple Operating System | \____________________________________/\_______________/ | | 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 ASCII7-bit character set 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 | | | +--------> UDPUser Datagram Protocol 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 VPNVirtual Private Network 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 | | \______________/ | | +--> MACApple Operating System 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 VPNVirtual Private Network 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 TCPTransport Control Protocol 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.
Previous versions:
| 1 |