DecentVPN

This page has been written considering the project "done". Maybe I should have set all verbs to future in order to stay humble... but it sure will make people more enthusiastic about our project like this ^^.

Feel 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... And 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 has just completed). The beginning of all of this is here. Sorry it's still yet in the French section of the Gentoo Linux Forum. 

• El_Goretto
  
• CryoGen
  
• KuRGaN
  
• PabOu
• kaworu
• Oupsman
• truc
• Poischack
  

• 12/10/06: Added the why decentVPN page.
• xx/08/06: Initial version of this page.

I- Description

Who is it intended for?

• Multi-sites corporations with high cost and/or limited bandwidths.
• Gamers.
• 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.
  For further explanations, see: why decentVPN?
• It provides a LAN interface: all products that have nothing but a LAN support will be Internet compliant. Especially old or crappy video games.

Why this project?

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...
• adjustable key sizes.
• advanced cryptographic modes: at least CBC, but also CTR for example (depend on cipher support).
• Concerning authentication several modules are proposed:
• Secure Remote Password (SRP) protocol. In this mode even weak passwords (i.e. low entropy) are secure.
• SSL certificates (feature taken from the OpenVPN project)
• In later releases: LDAP, RADIUS, SSH public/private keys (as putty or OpenSSH keys)...
• Server redundancy: the VPN won't become unavailable in case the original server hardware crashes.
• For gamers:
• LAN interface over Internet
• Maximized performances and lowest latency can be achieved by disabling securing features (like encryption), so that decentVPN only works on a fast rerouting mode.
• In later releases: 
• NAT-Transversal for clients without explicit port forwarding: decentVPN won't require any configuration to properly work behind a router.
• Proxy support.
• 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 at all.
• Rich security access features:
• Hierarchical "rooms" organization, similar to filesystems or 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 of a same VPN. It's a simplified version of what directories like LDAP or ActiveDirectory propose.
• There are 4 types of Nodes:
• Normal 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 diagram). 
• Resource 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.
• SuperServer Node:  the "root" of the decentVPN hierarchy. *nix/Linux people can think about their deer "/", windowsians about their "c:/". When connecting to the VPN, each 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.
• Secondary 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)

3.1- Server

• 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 have 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, and their session key. And that's all. (Remember, we are in the case of a single "room").
• When a client required a key to communicate to another one, the 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).

3.2- Client

• Authentication method and server address is set up.
• Connection to the server.
• Once authentication done, the client has a session key with the server, and gets cipher algorithm and its IP address and clients listing with their IP addresses (both real and VPN addresses).
• When a client want to communicate with another one, if he hasn't 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.