Last update: 08/08/06 (DD/MM/YY)
This page has
considering the project "done". Maybe I should have set all verbs
to future in order to stay humble... but it sure will
people more enthusiastic about our project like this ^^.
free to send me all
your comments either on my approximative English or on the project
itself. Please consider joining the project if you feel you can bring
some help (knowledge of how to lead an opensource projects, of law, of
concepts involved in decentVPN (security and network programming),
etc). At the moment, we should have basic theorical knowledge needed
about encryption and tunneling/VPN. But we aren't experts...
maybe we won't be talented enough to realize all the feature referenced
in the "in later releases"
section. But theses later features would make decentVPN pretty
fantastic even if they aren't in our primary objectives ^^
For the moment, we haven't officially launched and referenced
the project (inscription to SourceForge
is pending). The beginning of all of this is here.
Sorry it's still yet in the French section of the Gentoo Linux Forum.
Team so far (roles will be specified later):
Who is it intended for?
- Multi-sites corporations with high cost and/or
- Everyone who's looking for a high performance VPN solution.
What does it do?
- It secures all data flow between VPN nodes.
- Each node directly communicates with other nodes. There is
no bandwidth waste as in standard VPN solutions, where all data
flows are send to a server which behave like a router. In this case the
global VPN speed is then limited by the server availability and its
bandwidth allocated to the VPN (when the server or it's Internet
connection isn't totally dedicated to the VPN).
DecentVPN doesn't suffer from this horrible drawback: each client
bandwidth is exploited to its maximum capabilities.
- It provides a LAN interface: all products that have nothing
LAN support will be Internet compliant. Especially old or crappy video
II- Features List
- OS support: decentVPN is designed to run at least
on Linux, Windows 2000/XP. As OpenVPN
advertises OpenBSD, FreeBSD,
NetBSD, Mac OS X, and Solaris support for itself, it's not impossible
than decentVPN also will.
- For multi-sites corporations:
- DecentVPN won't require any "special" setup that
isn't already present if you use a standard VPN solution.
- Security features are fully custumisable according to
your proper needs:
- Concerning encryption (provided by the OpenSSL library):
- wide range of ciphers: 3DES, blowfish, AES...
- advanced cryptographic modes: at least CBC, but also
CTR for example (depend on cipher support).
- Concerning authentication several modules are proposed:
Remote Password (SRP) protocol. In this mode even weak
passwords (i.e. low entropy) are secure.
- SSL certificates (feature taken from the OpenVPN
later releases: LDAP, RADIUS, SSH public/private keys (as putty
- Server redundancy: the VPN won't become unavailable in
case the original server hardware crashes.
- For gamers:
- LAN interface over Internet
performances and lowest latency can be achieved by disabling
features (like encryption), so that decentVPN only works on a fast
- In later
- NAT-Transversal for clients without explicit port
forwarding: decentVPN won't require any configuration to properly work
behind a router.
- No Server mode: for small communities, no server
setup will be
required. As a consequence, security features tied to authentication
won't be as rich as with a server. This point is heavilly discussed, to
decide if this mode will be only proposed without any security feature
or not. Because a less secure network may not be considered as secure
- Rich security access features:
- Hierarchical "rooms" organization, similar to
logical trees. A room is an space where present clients can
communicate. Clients and servers are called Nodes (see below).
- Delegation of administration between decentVPN servers
same VPN. It's a simplified version of what directories like LDAP or
- There are 4 types of Nodes:
client Node: basically a physical person which
connect to the VPN. Each client of this type in a
subfolder/subroom/leaf is virtually present in all upper levels and so
can communicate with clients present in rooms all along the path the
client followed. (I'm not sure to explain it very well... I'll do a
Node: typically a webserver for example. This
type of node is only present in one room. So that only Normal Client
nodes that have been granted access to this room can join the Resource
Node: the "root" of the decentVPN
hierarchy. *nix/Linux people can think about their deer "/",
windowsians about their "c:/". When connecting to the VPN,
Node must present itself in front of him. Authentication is generally
done by him, but not in the case that the Node is referenced
on another server in the hierarchy.
Server Node (think of a better name...): as
explained, they are intended to manage a pool of Nodes (access
rights, and authentication data) so that the SuperServer Node is
released of too much local Nodes.
III- How it works (or it should do)
The following explanations don't cover the features from the "In later releases" section.
- Cipher algorithm and authentication method is set
up. User database is stored locally.
- Connection of a client.
- Once the client is authenticated, the server and the client
a session key they will keep secret, and that will last until the
client disconnects or is declared so. Idem for the allocated IP address.
Then he updates the clients listing, and send it to clients.
- The server keeps IP addresses information about clients,
their session key. And that's all. (Remember, we are in the
of a single "room").
- When a client required a key to communicate to another one,
server generates one, and keep it in memory until he is sure both
clients get it. Then he forget the key (so that if the server is
rooted, communications between clients won't be immediately in danger).
- Authentication method and server address is set up.
- Connection to the server.
- Once authentication done, the client has a session key with
server, and gets cipher algorithm and its IP address and clients
with their IP addresses (both real and VPN addresses).
- When a client want to communicate with another one, if he
already a key with him, he ask and get one from the server. As soon as
the other client get the key too, connexions can be established.
IV- Development planification
At a first view, decentVPN will make heavy use of OpenSSL
and its EVP
will be of a great help, either we decide to fork decentVPN from this
project or we start from scratch and take portions of code from it.
Involved libraries will include at least libpcap, libnet, and SRP
For the moment, no GUI is planed, but this point is open. In my humble
view, a web interface for server side would be great, and a
portable interface in gtk (or qt?) would do it for client
4.1 Network interactions
Authentication always succeed, a blank key is always generated between
clients. Communications between server and clients aren't ciphered.
IP allocations and routing should be fully effective.
DecentVPN messages format must be defined.
4.2 Authentication method
Implementation of SRP protocol authentication.
Maybe the SSL one too.
Client/Server session keys must be generated accordingly to the
Clients management on server effective.
4.3 Ciphering effective
Server generate a non null key for client-to-client connection.
Communication between all nodes (C-to-C, S-to-C) ares now ciphered.
4.4 Working on a fully distributed VPN, aka no server mode
We'll see then ^^