- Yavipin development has been stopped (I think). Hence I could
not get much support for this software, and I had to hack into the source code to get a look at what is happening.
This was very easy though.
[source]
The documentation that comes with yavipin is very terse, and not updated. Hence many options that are provided in the supporting document are either wrong or incomplete. It will be great if someone could include a patch for yavipin to read its configuration options from a file, rather than the command line. (Hint: Read flex (Gnu implementation for LEX) and Bison (Gnu implementation for YACC)) - You can install yavipin by:
- If you are using OpenSSL-0.9.6b, then you can just download the latest tarball and compile it using ./configure; make ; make install. Everything goes on smoothly.
- If you are using OpenSSL-0.9.7a, then you are in trouble. Fortunately someone
has provided an RPM (
yavipin-0.9.5-1.i386.rpm). Use rpm -ivh to install this.
Skip the next two steps. - The above method, however, does not allow to debug/hack into the code. Hence I had to download/compile/install OpenSSL-0.9.6b in a non-system directory, even though I had a higher version (0.9.7a). I have installed the OpenSSL-0.9.6b in /home/shashank/openssl-0.9.6b directory. This is done by manuipulating some of the config script options, that comes with openssl-0.9.6b.
- However this does not end here. The configure script that comes with Yavipin, does not recognise the non-system directories and aborts. Hence I had to follow an unnatural way of compiling yavipin on another machine, and then transferring the Makefiles to this machine and changing some options in the makefile. More interested readers can look here for more information.
- I am asssuming that we are using the following setup with mia
as the client and zidler as the server .
- In Yavipin parlace, the server is the responder and the client is the initiator. Hence in our case, we have mia as the initiator and zidler as the responder
- yavind gets installed in /usr/sbin/yavipind. However, since I wanted to insert some debuging codes,
I use the binary that is present in the source directory tree.
A help message can be displayed using the command yavipind -h.
However this has some errors. I am listing below the help, that I think should have been there.
Updated messages are marked with ***.
shashank@zidler:/etc/yavipin# yavipind -h yavipind version 0.9.5 Usage: yavipind [--help] (--responder|--initiator) --passwd=pwfile [--src=[addr][:port]] --dst=addr[:port] [--ifup script] [--ifdown script] [--comp] [--nodeamon] --src=[addr][:port] : specify the source addr and port --dst= addr[:port] : specify the destination addr and port --responder : be the tunnel responder --initiator : be the tunnel initiator --p pwfile : give the file's name containing the authentication password *** --ifup=script : give the script's filename to run when the tunnel goes UP --ifdown=script : give the script's filename to run when the tunnel goes DOWN --comp=DEFAULT : (DEFAULT | ZLIB) There is error in code. Hence this must be provided on cmdline *** --nodaemon : do not daemonize (usefull to debug) (Cannot use -f switch for this) *** --enc=algo : set a given algorithm for the packet encryption (DES-CBC(default) | BF-SBC) *** --mac=algo : set a given algorithm for the packet authentication (HMAC_MD5_96) *** --help : display this short inlined help --version : display the software version
- Before starting the yavipin daemon, we need to configure some files. I have made a directory
/etc/yavipin on both mia and zidler. In this directory, i keep the password file, ip-up and ip-down scripts
as listed below:
- ON ZIDLER:
Yavipin daemon passes the tunnel name tun0 (say) as the first command-line argument to the
ip-up and ip-down scripts.
shashank@zidler:/etc/yavipin# cat password abcd1234 ------------------------------------------------------------- shashank@zidler:/etc/yavipin# cat ip-up #!/bin/sh echo "[Yavipn].. ip-up script is run" ifconfig $1 192.168.254.201 netmask 255.255.255.255 route add -net 192.168.254.200 netmask 255.255.255.255 dev $1 route add -net 192.168.0.0 netmask 255.255.255.0 dev $1 ------------------------------------------------------------- shashank@zidler:/etc/yavipin# cat ip-down #!/bin/sh echo "[Yavipn].. ip-down script is run" route del -net 192.168.254.200 netmask 255.255.255.255 dev $1 route del -net 192.168.0.0 netmask 255.255.255.0 dev $1 ifconfig $1 down
- ON MIA:
Yavipin daemon passes the tunnel name tun0 (say) as the first command-line argument to the
ip-up and ip-down scripts.
[shashank@mia yavipin]# cat password abcd1234 ------------------------------------------------------------- [shashank@mia yavipin]# cat ip-up #!/bin/sh echo "[Yavipn].. ip-up script is run" ifconfig $1 192.168.254.200 netmask 255.255.255.255 route add -net 192.168.254.201 netmask 255.255.255.255 dev $1 route add -net 192.168.2.0 netmask 255.255.255.0 dev $1 ------------------------------------------------------------- [shashank@mia yavipin]# cat ip-down #!/bin/sh echo "[Yavipn].. ip-down script is run" route del -net 192.168.254.201 netmask 255.255.255.255 dev $1 route del -net 192.168.2.0 netmask 255.255.255.0 dev $1 ifconfig $1 down
- ON ZIDLER:
Yavipin daemon passes the tunnel name tun0 (say) as the first command-line argument to the
ip-up and ip-down scripts.
- After having all this in place, one can have start the daemons on both the responder and initiator as follows:
- ON RESPONDER: (ZIDLER)
shashank@zidler:~/temp/yavipn# ./yavipind --nodaemon --responder --src 131.193.50.184:6656 \ -p /etc/yavipin/password --ifup=/etc/yavipin/ip-up --ifdown=/etc/yavipin/ip-down --comp=ZLIB \ --enc=BF-SBC --mac=HMAC_MD5_96
- ON INITIATOR: (MIA)
shashank@mia:~/temp/yavipin-0.9.5# ./yavipind --nodaemon --initiator --dst 131.193.50.184:6656 \ -p /etc/yavipin/password --ifup=/etc/yavipin/ip-up --ifdown=/etc/yavipin/ip-down --comp=ZLIB \ --enc=BF-SBC --mac=HMAC_MD5_96
- ON RESPONDER: (ZIDLER)
- Use ifconfig to verify that the tunnel is up.
zidler#> ifconfig --SNIP-- tun0 Link encap:Point-to-Point Protocol inet addr:192.168.254.201 P-t-P:192.168.254.201 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1449 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ----------------------------------------------------------------------------------- mia#> ifconfig --SNIP-- tun0 Link encap:Point-to-Point Protocol inet addr:192.168.254.200 P-t-P:192.168.254.200 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1449 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) - Use netstat -rn and ping to verify that the networks are reachable.
- Kill the yavipind process to bring down the interface.
- The below diagram traces the path taken by a packet as it travels over the tunnel formed by Yavipin.
- The TCP/IP/Ethernet layers add known amount of header/trailer which are trivial to find out. Hence, I will not explain them here. I will concentrate only on the overhead added by the Tun/Tap layer and the Yavipin layer.
- The Tun/Tap layer transparently passes any IP packet to the application, without adding any overhead. (Write WHY)
- You will find that Yavipin bundles packet as:
6-byte Header 4-byte Compression Header n1-byte payload; n2-byte random padding; (Added to make [Header + Comp_header + payload + padding + padding_len] a multiple of BLOCK_SIZE for the cipher.) 1-byte padding_length. 12-byte MAC (message authentication code); MD5-96. - Let us assume that we are using BF-CBC. Suppose that the input to the Yavipin layer is
a packet of length 128 bytes, then you can calculate the total overhead added by yavipin as follows:
- Find out what block size is used by the cipher. Since we are using Blowfish, the BLOCK_SIZE is 8 bytes.
- Calculate [8 - (6 + 4 + 128 + 1)%8] = 5. Hence the number of padding bytes will be 5.
- Now add: MD5 MAC (12 Bytes) to the above packet to give a packet of 156 Bytes. We verifed this with experiments too.
- Thus we conclude that the yavipin layer adds a minimum of (6(Header) + 4(Comp_header) + 0(padding) + 1(padding_len) + 12(MAC=md5) = 23 bytes) and maximum of ( 6(Header) + 4(Comp_header) + 7(padding) + 1(padding_len) + 12(MAC=md5) = 30 bytes).
- Yavipin does not really support operation without compression. However I had to modify the source code to acheive this. You can refer to the modification here.
- Assuming no compression mechanism is used
and using the cipher suite (BF-SBC), we conducted a series of experiments with
varying application input sizes.
The input data for this experiment was totally random.
An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
The results are presented below here.
- We conducted a series of experiments, with full compression enabled. The results are presented below here.
- The input data for this experiment was totally random. An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
- Using compression, it is not possible to estimate the amount of overhead, as the amount of compression really depends on the entropy in the data. It is entirely possible for the data on the wire to be lesser in size to the input data. For e.g. when we used an input data of size 1200 bytes (each having a value "S"), we found that the packet size on the wire was just 130 Bytes.
- Yavipin tunnels, do not have inbuilt routing mechanisms. As a result the user
has to take care of establishing routes to remote networks. This can be done in the following ways:
- Static routes can be added after the link comes up. Commands similar to the below are specified in
/etc/yavipin/ip-up scripts.
route add -net network/netmask gw gateway-ip
Although the above method is simple for small networks, it becomes exceedingly difficult to maintain such routes one your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network. - Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.
- Static routes can be added after the link comes up. Commands similar to the below are specified in
/etc/yavipin/ip-up scripts.
- Yavipin uses the OpenSSL interface for its ciphers/MAC. However a quick look at the source, will reveal that it is easy to add proprietary ciphers/MAC.
- Yavipin provides only one compression algorithm (zlib). It is, however, very easy to add one's own compression algorithm by modification of the source.
- The Yavipin solution for forming VPN's is highly unscalable. (This may not be true
- For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.