520 lines
24 KiB
Text
520 lines
24 KiB
Text
This is tinc.info, produced by makeinfo version 4.1 from tinc.texi.
|
||
|
||
INFO-DIR-SECTION Networking tools
|
||
START-INFO-DIR-ENTRY
|
||
* tinc: (tinc). The tinc Manual.
|
||
END-INFO-DIR-ENTRY
|
||
|
||
This is the info manual for tinc, a Virtual Private Network daemon.
|
||
|
||
Copyright (C) 1998-2002 Ivo Timmermans <itimmermans@bigfoot.com>,
|
||
Guus Sliepen <guus@sliepen.warande.net> and Wessel Dankers
|
||
<wsl@nl.linux.org>.
|
||
|
||
$Id: tinc.texi,v 1.8.4.28 2002/04/09 11:43:29 guus Exp $
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual 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.
|
||
|
||
|
||
File: tinc.info, Node: The UDP tunnel, Next: The meta-connection, Prev: The connection, Up: The connection
|
||
|
||
The UDP tunnel
|
||
--------------
|
||
|
||
The data itself is read from a character device file, the so-called
|
||
_virtual network device_. This device is associated with a network
|
||
interface. Any data sent to this interface can be read from the device,
|
||
and any data written to the device gets sent from the interface. Data
|
||
to and from the device is formatted as if it were a normal Ethernet
|
||
card, so a frame is preceded by two MAC addresses and a _frame type_
|
||
field.
|
||
|
||
So when tinc reads an Ethernet frame from the device, it determines
|
||
its type. When tinc is in it's default routing mode, it can handle IPv4
|
||
and IPv6 packets. Depending on the Subnet lines, it will send the
|
||
packets off to their destination. In the `switch' and `hub' mode, tinc
|
||
will use broadcasts and MAC address discovery to deduce the destination
|
||
of the packets. Since the latter modes only depend on the link layer
|
||
information, any protocol that runs over Ethernet is supported (for
|
||
instance IPX and Appletalk).
|
||
|
||
After the destination has been determined, a sequence number will be
|
||
added to the packet. The packet will then be encrypted and a message
|
||
authentication code will be appended.
|
||
|
||
When that is done, time has come to actually transport the packet to
|
||
the destination computer. We do this by sending the packet over an UDP
|
||
connection to the destination host. This is called _encapsulating_,
|
||
the VPN packet (though now encrypted) is encapsulated in another IP
|
||
datagram.
|
||
|
||
When the destination receives this packet, the same thing happens,
|
||
only in reverse. So it checks the message authentication code,
|
||
decrypts the contents of the UDP datagram, checks the sequence number
|
||
and writes the decrypted information to its own virtual network device.
|
||
|
||
To let the kernel on the receiving end accept the packet, the
|
||
destination MAC address must match that of the virtual network
|
||
interface. If tinc is in it's default routing mode, ARP does not work,
|
||
so the correct destination MAC cannot be set by the sending daemons.
|
||
tinc solves this by always overwriting the destination MAC address with
|
||
fe:fd:0:0:0:0. That is also the reason why you must set the MAC address
|
||
of your tap interface to that address.
|
||
|
||
|
||
File: tinc.info, Node: The meta-connection, Prev: The UDP tunnel, Up: The connection
|
||
|
||
The meta-connection
|
||
-------------------
|
||
|
||
Having only an UDP connection available is not enough. Though
|
||
suitable for transmitting data, we want to be able to reliably send
|
||
other information, such as routing and session key information to
|
||
somebody.
|
||
|
||
TCP is a better alternative, because it already contains protection
|
||
against information being lost, unlike UDP.
|
||
|
||
So we establish two connections. One for the encrypted VPN data,
|
||
and one for other information, the meta-data. Hence, we call the second
|
||
connection the meta-connection. We can now be sure that the
|
||
meta-information doesn't get lost on the way to another computer.
|
||
|
||
Like with any communication, we must have a protocol, so that
|
||
everybody knows what everything stands for, and how she should react.
|
||
Because we have two connections, we also have two protocols. The
|
||
protocol used for the UDP data is the "data-protocol," the other one is
|
||
the "meta-protocol."
|
||
|
||
The reason we don't use TCP for both protocols is that UDP is much
|
||
better for encapsulation, even while it is less reliable. The real
|
||
problem is that when TCP would be used to encapsulate a TCP stream
|
||
that's on the private network, for every packet sent there would be
|
||
three ACKs sent instead of just one. Furthermore, if there would be a
|
||
timeout, both TCP streams would sense the timeout, and both would start
|
||
re-sending packets.
|
||
|
||
|
||
File: tinc.info, Node: The meta-protocol, Next: Security, Prev: The connection, Up: Technical information
|
||
|
||
The 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 *Note Authentication
|
||
protocol::. After a successful 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 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
|
||
| | +--> prefixlength
|
||
| +--------> IPv4 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.
|
||
|
||
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
|
||
requester.
|
||
|
||
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 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
|
||
--------------------------------------------------------------------------
|
||
|
||
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.
|
||
|
||
daemon message
|
||
--------------------------------------------------------------------------
|
||
origin PING
|
||
dest. PONG
|
||
--------------------------------------------------------------------------
|
||
|
||
This basically covers what is sent over the meta connection by tinc.
|
||
|
||
|
||
File: tinc.info, Node: Security, Prev: The meta-protocol, Up: Technical information
|
||
|
||
About tinc's encryption and other security-related issues.
|
||
==========================================================
|
||
|
||
tinc got its name from "TINC," short for _There Is No Cabal_; the
|
||
alleged Cabal was/is an organisation that was said to keep an eye on the
|
||
entire Internet. As this is exactly what you _don't_ want, we named
|
||
the tinc project after TINC.
|
||
|
||
But in order to be "immune" to eavesdropping, you'll have to encrypt
|
||
your data. Because tinc is a _Secure_ VPN (SVPN) daemon, it does
|
||
exactly that: encrypt. tinc by default uses blowfish encryption with
|
||
128 bit keys in CBC mode, 32 bit sequence numbers and 4 byte long
|
||
message authentication codes to make sure eavesdroppers cannot get and
|
||
cannot change any information at all from the packets they can
|
||
intercept. The encryption algorithm and message authentication
|
||
algorithm can be changed in the configuration. The length of the message
|
||
authentication codes is also adjustable. The length of the key for the
|
||
encryption algorithm is always the default length used by OpenSSL.
|
||
|
||
* Menu:
|
||
|
||
* Authentication protocol::
|
||
* Encryption of network packets::
|
||
|
||
|
||
File: tinc.info, Node: Authentication protocol, Next: Encryption of network packets, Prev: Security, Up: Security
|
||
|
||
Authentication protocol
|
||
-----------------------
|
||
|
||
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 received, both ends have proved
|
||
their identity. Further information is exchanged.
|
||
|
||
client ACK 655 12.23.34.45 123 0
|
||
| | | +-> options
|
||
| | +----> estimated weight
|
||
| +------------> IP address of server as seen by client
|
||
+--------------------> UDP port of client
|
||
|
||
server ACK 655 21.32.43.54 321 0
|
||
| | | +-> options
|
||
| | +----> estimated weight
|
||
| +------------> IP address of client as seen by server
|
||
+--------------------> UDP 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
|
||
cryptographic 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.
|
||
|
||
|
||
File: tinc.info, Node: Encryption of network packets, Prev: Authentication protocol, Up: Security
|
||
|
||
Encryption of network packet
|
||
----------------------------
|
||
|
||
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 retrieve it. The packet is stored in a queue while waiting for the
|
||
key to arrive.
|
||
|
||
The UDP packet containing the network packet from the VPN has the
|
||
following layout:
|
||
|
||
... | IP header | UDP header | seqno | VPN packet | MAC | UDP trailer
|
||
\___________________/\_____/
|
||
| |
|
||
V +---> digest algorithm
|
||
Encrypted with symmetric cipher
|
||
|
||
So, the entire VPN packet is encrypted using a symmetric cipher. A
|
||
32 bits sequence number is added in front of the actual VPN packet, to
|
||
act as a unique IV for each packet and to prevent replay attacks. A
|
||
message authentication code is added to the UDP packet to prevent
|
||
alteration of packets. By default the first 4 bytes of the digest are
|
||
used for this, but this can be changed using the MACLength
|
||
configuration variable.
|
||
|
||
|
||
File: tinc.info, Node: About us, Next: Concept Index, Prev: Technical information, Up: Top
|
||
|
||
About us
|
||
********
|
||
|
||
* Menu:
|
||
|
||
* Contact Information::
|
||
* Authors::
|
||
|
||
|
||
File: tinc.info, Node: Contact Information, Next: Authors, Prev: About us, Up: About us
|
||
|
||
Contact information
|
||
===================
|
||
|
||
tinc's website is at <http://tinc.nl.linux.org/>, this server is
|
||
located in the Netherlands.
|
||
|
||
We have an IRC channel on the Open Projects IRC network. Connect to
|
||
irc.openprojects.net (http://openprojects.nu/services/irc.html), and
|
||
join channel #tinc.
|
||
|
||
|
||
File: tinc.info, Node: Authors, Prev: Contact Information, Up: About us
|
||
|
||
Authors
|
||
=======
|
||
|
||
Ivo Timmermans (zarq) (<itimmermans@bigfoot.com>)
|
||
Main coder/hacker and maintainer of the package.
|
||
|
||
Guus Sliepen (guus) (<guus@sliepen.warande.net>)
|
||
Originator of it all, co-author.
|
||
|
||
Wessel Dankers (Ubiq) (<wsl@nl.linux.org>)
|
||
For the name `tinc' and various suggestions.
|
||
|
||
We have received a lot of valuable input from users. With their
|
||
help, tinc has become the flexible and robust tool that it is today.
|
||
We have composed a list of contributions, in the file called `THANKS' in
|
||
the source distribution.
|
||
|
||
|
||
File: tinc.info, Node: Concept Index, Prev: About us, Up: Top
|
||
|
||
Concept Index
|
||
*************
|
||
|
||
* Menu:
|
||
|
||
* ACK: Authentication protocol.
|
||
* ADD_EDGE: The meta-protocol.
|
||
* ADD_SUBNET: The meta-protocol.
|
||
* Address: Host configuration variables.
|
||
* AddressFamily: Main configuration variables.
|
||
* ANS_KEY: The meta-protocol.
|
||
* arp <1>: Error messages.
|
||
* arp: Network interfaces.
|
||
* authentication: Authentication protocol.
|
||
* binary package: Building and installing tinc.
|
||
* BindToInterface: Main configuration variables.
|
||
* Cabal: Security.
|
||
* CHAL_REPLY: Authentication protocol.
|
||
* CHALLENGE: Authentication protocol.
|
||
* CIDR notation: Host configuration variables.
|
||
* Cipher: Host configuration variables.
|
||
* client: How connections work.
|
||
* command line: Runtime options.
|
||
* Compression: Host configuration variables.
|
||
* connection: The connection.
|
||
* ConnectTo: Main configuration variables.
|
||
* daemon: Running tinc.
|
||
* data-protocol: The meta-connection.
|
||
* Debian: Configuring the kernel.
|
||
* debug level: Runtime options.
|
||
* DEL_EDGE: The meta-protocol.
|
||
* Device: Main configuration variables.
|
||
* device files: Device files.
|
||
* Digest: Host configuration variables.
|
||
* encapsulating: The UDP tunnel.
|
||
* encryption: Encryption of network packets.
|
||
* ethertap: Configuring the kernel.
|
||
* example: Example configuration.
|
||
* frame type: The UDP tunnel.
|
||
* FreeBSD: Supported platforms.
|
||
* hardware address: Network interfaces.
|
||
* Hostnames: Main configuration variables.
|
||
* hub: Main configuration variables.
|
||
* ID: Authentication protocol.
|
||
* ifconfig: Network interfaces.
|
||
* IndirectData: Host configuration variables.
|
||
* Interface: Main configuration variables.
|
||
* IRC: Contact Information.
|
||
* Kernel-HOWTO: Configuring the kernel.
|
||
* key generation: Generating keypairs.
|
||
* KEY_CHANGED: The meta-protocol.
|
||
* KeyExpire: Main configuration variables.
|
||
* libraries: Libraries.
|
||
* license: OpenSSL.
|
||
* Linux: Supported platforms.
|
||
* MAC address: Network interfaces.
|
||
* MACExpire: Main configuration variables.
|
||
* MACLength: Host configuration variables.
|
||
* meta-protocol: The meta-connection.
|
||
* META_KEY: Authentication protocol.
|
||
* Mode: Main configuration variables.
|
||
* multiple networks: Multiple networks.
|
||
* Name: Main configuration variables.
|
||
* netlink_dev: Configuring the kernel.
|
||
* netmask: Network interfaces.
|
||
* netname: Multiple networks.
|
||
* Network Administrators Guide: Configuration introduction.
|
||
* OpenBSD: Supported platforms.
|
||
* OpenSSL: OpenSSL.
|
||
* options: Runtime options.
|
||
* PEM format: Host configuration variables.
|
||
* PING: The meta-protocol.
|
||
* PingTimeout: Main configuration variables.
|
||
* platforms: Supported platforms.
|
||
* PONG: The meta-protocol.
|
||
* Port: Host configuration variables.
|
||
* port numbers: Other files.
|
||
* PriorityInheritance: Main configuration variables.
|
||
* private: VPNs.
|
||
* PrivateKey: Main configuration variables.
|
||
* PrivateKeyFile: Main configuration variables.
|
||
* PublicKey: Host configuration variables.
|
||
* PublicKeyFile: Host configuration variables.
|
||
* RedHat: Configuring the kernel.
|
||
* release: Supported platforms.
|
||
* REQ_KEY: The meta-protocol.
|
||
* requirements: Libraries.
|
||
* router: Main configuration variables.
|
||
* runtime options: Runtime options.
|
||
* scalability: tinc.
|
||
* server: How connections work.
|
||
* Solaris: Supported platforms.
|
||
* Subnet: Host configuration variables.
|
||
* SVPN: Security.
|
||
* switch: Main configuration variables.
|
||
* TCP: The meta-connection.
|
||
* TCPonly: Host configuration variables.
|
||
* TINC: Security.
|
||
* tinc: Introduction.
|
||
* tinc-up: Network interfaces.
|
||
* tincd: tinc.
|
||
* Traditional VPNs: tinc.
|
||
* tun: Configuring the kernel.
|
||
* UDP <1>: Encryption of network packets.
|
||
* UDP: The UDP tunnel.
|
||
* virtual: VPNs.
|
||
* virtual network device: The UDP tunnel.
|
||
* VPN: VPNs.
|
||
* vpnd: tinc.
|
||
* website: Contact Information.
|
||
* zlib: zlib.
|
||
|
||
|