VPN Implementation

The implementation of a Virtual Private Network (VPN)

Ivo Timmermans <zarq@iname.com>


Introduction

The objective of this document is to come to a generic way of establishing a Virtual Private Network (VPN) on top of the existing Internet. Our primary target is a Linux 2.1 kernel running on Intel x86 hardware.

Since this project is still in its design phase, all comments are more than welcome.

Overview

A Virtual Private Network or VPN is a network that can only be accessed by a few elected computers that participate.

The idea is to encapsulate packets for the VPN in another packet that get sent over the real Internet to the other connections on the VPN. This will be done using a UDP connection on port 24.

This way, we can easily encrypt the data that goes over the virtual network connection.

The connections will be set up using a VPN daemon, vpnd, that uses the ethertap device to copy data from the VPN connection to the kernel and back again.

The Connection

The data that was gathered from the ethertap device will be sent over a UDP connection on port 24.

But there's more. Not all data is actual VPN data. There will have to be a way to set up dynamic routing tables, so that if a new connection between two vpnd's gets set up, the other vpnd's currently on the VPN get notified of this event, and dynamically change their routing tables accordingly.

This data, and possibly also dynamic encryption keys, will go over a second, meta-connection. This will be a connection on port 24 of TCP.

Connection Metadata

There are only a few fings that will use the meta-connection. Right now, these would be:

Encryption

There are some ways in which we could encrypt the VPN data streams.

Possibilities include DES, RSA, IDEA, and Blowfish.

We will use Blowfish (http://www.counterpane.com/blowfish.html), because it is unpatented and license-free.

Key Exchange

You can't just send a private encryption key te your peer, because somebody else may be eavesdropping. So you'll have to negotiate over a shared but secret key. One way to do this is by using the "Diffie-Hellman key exchange" protocol (http://www.rsa.com/rsalabs/faq/html/3-6-1.html). The idea is as follows.

You have two participants A and B that want to agree over a shared secret encryption key. Both parties have some large prime number p and a generator g. These numbers may be known to the outside world, and hence may be included in the source distribution.

Both parties then generate a secret key. A generates a, and computes g^a mod p. This is then sent to B; while B computes g^b mod p, and transmits this to A, b being generated by B. Both a and b must be smaller than p-1.

These private keys are generated upon startup, and they are not changed while the connection exists. A possible feature in the future is to dynamically change the keys, every hour for example.

Both parties then calculate g^ab mod p = k. k is the new, shared, but still secret key.

To obtain a key k of a sufficient length (128 bits in our vpnd), p should be 2^129-1 or more.

Authentification

Because the Diffie-Hellman protocol is in itself vulnerable to the "man-in-the-middle attack," we should introduce an authentification system.

We will let A transmit a passphrase that is also known to B encrypted with g^a, before A sends this to B. This way, B can check whether A is really A or just someone else.

This passphrase should be 2304 bits for a symmetric encryption system. But since an asymmetric system is more secure, we could do with 2048 bits. This only holds if the passphrase is very random.

These passphrases could be stored in a file that is non-readable by anyone else but root; e.g. `/etc/vpn/passphrases'.

The only thing that needs to be taken care of is how A announces its passphrase to B.

The Protocol

This chapter describes the protocol in detail.

first byte: protocol version
second byte: request id

Setting up your Computer

Configuring the kernel

Since this particular implementation only runs on 2.1 or higher Linux kernels, you should grab one. At the time of this writing, the 2.1 series are still being developed. The 2.1 series, however, are development kernels, and may not be as stable as the 2.0 series. Please keep this in mind when reading further.

Here are the options you have to turn on/off when configuring a new kernel using "make menuconfig"(1).

Code maturity level options
[*] Prompt for development and/or incomplete code/drivers
Networking options
[*] Kernel/User netlink socket
[ ] Routing messages
<*> Netlink device emulation
Network device support
<*> Ethertap network tap

Then, after having set up other options, build the kernel and boot it.

Configuring for Modules

If you have selected any of the above to be built as a module, it's a good idea to add these lines to `/etc/modules.conf'(2).

alias tap0 ethertap
alias char-major-36 netlink_dev

Files Needed

Device files

First, you'll need the special device file(s) that form the interface between the kernel and the vpnd.

mknod -m 600 /dev/tap0 c 36 16
chown 0.0 /dev/tap0

The permissions now will be such that only the super user may read/write to this file. You'd want this, because otherwise eavesdropping would become a tad too easy. This does, however, imply that you'd have to run vpnd as root.

If you want to, you may also create more device files, which would be numbered 0...15, with minor device numbers 16...31. They all should be owned by root and have permission 600.

`/etc/networks'

You may add a line to `/etc/networks' so that your vpn will get a symoblic name. For example:

vpn 10.0.0.0

`/etc/services'

You may add this line to `/etc/services'. The effect is that you may supply a `vpn' as a valid port number to some programs.

# 24 - virtual private network
vpn             24/tcp
vpn             24/udp

Concept Index

Jump to: b - c - d - m - p - s - v

b

  • Blowfish
  • c

  • Connection
  • d

  • Diffie-Hellman
  • m

  • man-in-the-middle attack
  • meta-connection
  • p

  • passphrase
  • s

  • secret key
  • v

  • VPN
  • vpnd

  • This document was generated on 16 December 1998 using the texi2html translator version 1.52.