Yavipin is a package that can be used to build a VPN between two hosts using some of the most advanced and sophisticated cryptography available. Learn more about the VPN that focuses on network efficiency, usability, and is highly secure.
Yavipin is a secure tunnel
(i.e. 2 peers securely forwarding packets toward each other)
using the state of art in network security.
It adds innovative features when needed such as a
secure pmtu discovery. This text aims to be a comprehensive
overview of yavipin's capabilities and motivations.
Yavipin stands for Yet another VPN.
I wrote a new secure tunnel even if numerous are already available
mainly because they don't satisfy my needs in security, network efficiency
or usability. I published some of the security holes i know in
alternatives such as
VTun
or tinc.
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 Factsheet
When 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.
Network efficiency:
- 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).
Security Strengths:
- 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 Author
Jerome 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.
Only registered users can write comments. Please login or register. Powered by AkoComment! |