Discover LinuxSecurity Features
Building a VPN Using Yavipin
The most popular alternatives are freeS/WAN and tunneling over SSH which are both standards. IP tunneling over SSH doesn't fit the same need because SSH hasn't been designed for tunneling. SSH is over TCP so is vulnerable to any attack on TCP (e.g. TCP syn flood especially with Linux which doesn't enable TCP syn cookie by default). It adds overhead as TCP header is larger than UDP one. Most of the time, it ends with TCP over IP over SSH over TCP over IP which is inefficient as the 2 TCP layers conflict with each other and the timers get confused. The other alternative, FreeS/WAN, uses IPSec protocols (IKE, ESP, AH) which remain at the datagram level, closer to Yavipin than SSH. Nevertheless, IKE is known to be uselessly complex, then hard to configure. It is vulnerable to several DoS (no effective cookie, CPU hogging vs aggressive mode, see Simpson for details). ESP/AH uses the default IPv4 path MTU discovery which is vulnerable to DoS (e.g. reduce the MTU to 68byte), so most implementors choose either to be vulnerable or not to discover MTU and potentially cause useless packet fragmentations with all the disadvantages in security, efficiency and connectivity. DES CBC with explicit random IV, the default ESP encryption, is vulnerable to birthday attack, a rather theoretical flaw but still.
Yavipin runs fully in Linux user-space so there is no need to recompile or patch the kernel at each update. It has been though to be easy to set up but still be very flexible. The minimal setup informations are the authentication key and the IP addresses of each peer. Moreover, user's scripts launched when the VPN starts or ends provide to the administrator a good flexibility. The man page includes a step by step guide to configure Yavipin. Yavipin can be used to secure the traffic between boxes or sites, as it is the most popular usage of VPNs. Additionally, as some wireless LANs have security issues, Yavipin can be used to protect the traffic between the computer and the wireless relay.
Each forwarded packet is encrypted and authenticated so an attacker can't read the original data or modify them (unlike VTun or tinc). Moreover it uses strict anti-replay and no packet can be accepted twice. A eavesdropper can't take a packet, keep it for a while and make it accept a second time by the destination (OSPFv2, RIPv2, VTun and tinc are vulnerable to this attack). Additionally, Yavipin protects against DoS ala TCP syn flood using a cookie exchange during the connection establishment (RFC2522.3). It provides forward secrecy so even if the attacker cracks the box, he won't be able to decrypt network traffic older than a given delay (default 10min).
Yavipin is considered network efficient because it has a small packet overhead (26bytes vs 32bytes for ESP with DES+MD5, the IPsec default), seamlessly works over NAT unlike IPsec and allow to compress forwarded packets. Moreover, it operates at the link layer (e.g. ethernet, ppp). This design choice has several advantages. First, Yavipin is able to forward any kind of packets (e.g. IPv4, IPv6, IPX or other). Moreover it allow to directly reuse any tool designed for network device, as Yavipin uses a virtual device (e.g. tun0, tap0). For example, it is possible to set up a firewall on the VPN using ipchains/netfilter, to do traffic shaping using the kernel's traffic control or to use auto-configuration tools over it (e.g. DHCP, ICMP Router).
In the future, i plan improve the DoS resistance against attackers who don't try to hide their IP addresses by using puzzles. Moreover i will include public key authentication using certificates to ease the deployment and the key management. To avoid efforts duplication, i plan to split Yavipin into a executable and a shared library so other tunneling softwares could use the encryption and authentication of the packets and the key establishment of Yavipin. Tinc's author already manifested his interest.
As any networking application and especially security ones, Yavipin needs a lot of testing before being fully trusted so i would be glad to assist any tester. Yavipin is yet another VPN but the good one when IPsec compliance isn't required, in my (likely biased :) opinion.
Yavipin FactsheetWhen designing the protocol and writting the software, the author used the following criteria: the security MUST as strong as reasonably possible, yavipin SHOULD be network efficient, easy to use and install.
- small packet overhead: 26bytes (e.g. ESP with DES+MD5 is 32byte)
- Packet compression: Forwarded packets may be compressed using deflate (gzip). (WORK: add stat about efficiency)
- NAT compatible: yavipin's tunnel may be establish over NAT as all packets of a tunnel are sent over a single UDP/IPv4 connection. Moreover the peer unreachability detection periodically send packets which prevent the NAT engine from timing out the connection state.
- Peer unreachabilty detection: If the other peer becomes unreachable, it will be detected. It is done ala IPv6 neighbours discovery (rfc2461.7).
- Gracefull shutdown: If a peer purposely stops, it will notify the other which is immediatly aware of it.
Simplicity of Use
- Fully in userspace: No need to recompile the kernel
- reuse existing tools: As yavipin use a virtual device, it is possible to apply to the tunnel any tool designed for network device. For example, it is possible to set up a firewall using ipchains/netfilter or to do traffic shapping using the kernel's traffic control (see tc).
- packet security: each packet exchanged during the connection is encrypted using blowfish CFB and authenticated with HMAC-MD5 96bits.
- protection against packet replay: It uses strict anti-replay and no packet can be accepted twice. A eavedropper can't take a packet, keep it for a while and make it accept a second time by the destination.
- Efficient session key renewal: It uses hash chains for efficiency. It allows smooth key transition not to cause any packet loss during the renewal. It provides forward secrecy inside the connection.
- Protect DoS ala TCP syn : It uses cookie exchange (rfc2522.3) during the connection establishement.
- Forward secrecy : Even if the attacker cracks the box, he won't be able to decrypt network traffic older than a given delay (default 10min). The diffie-hellman private key and the session key are periodically renewed and securely erased from memory.
About the AuthorJerome etienne is mainly interested in security, networking and cryptography. He likes to design security protocols (proposed IPsec's improvements, yavipin) and to break them (found security holes in OSPFv2, RIPv2, VTun, tinc and the encrypted loop device for linux). As an IP stack maintainer, he implemented various IP protocols (TCP, IPsec IKE/ESP/AH, OSPFv2, RIPv1 and v2, SNMPv1 and v2 with rfc1213 MIBs, IGMPv1 and v2, RTP/RTCP). In privacy, he designed a 'new generation protocol' for zeroknowledge to anonymize IP traffic and help to launch the nymip project. Maybe one day, he will do a PhD on it.