(usagi-users 03707) Re: shim6 implementation

Miika Komu wrote:

>
> Had a quick look and it seems pretty good job! I am also curious that 
> why did you end up implementing shim6 completely in kernelspace?

It appeared to me as being the more natural way to do things : shim6 
work (at least for accounting) has to be done for each packet received 
or sent, and it seems to me little comfortable to have a switch to user 
space so many times. Do you have in mind a part of the implementation 
that should be moved to user space ?

>
> Can you give simple HOWTO instructions on testing the code? Have you 
> tested it also with different IPsec modes?

The way to compile shim6 files inside the kernel is explained in the 
readme.txt file (in the tar.gz available at 
http://gforge.info.ucl.ac.be/projects/shim6/). Now about the tests :
- A simple way to test it is to compile the kernel as UML (User Mode 
Linux, http://user-mode-linux.sourceforge.net/). This way you can 
prepare an arbitrary network and test multihoming.
- Another option is to set up a real network, for example two hosts 
separated by two routers, each advertising two prefixes to each host.

Here is what i have done :
- I had two UMLs running, directly connected by two different 'virtual 
wires' (tuntap ethernet), one UML had addresses fec0::2 and fec0::20. 
The one other fec0::3 and fec0::30.
- Then 'ssh fec0::3' this works as for a normal ssh session. Now we can 
see a new entry in /proc/net/shim6, which gives information about the 
new shim6 context (the current version triggers a shim6 context creation 
for each new exchange).
- On the other host (ssh server), we may now do something like 'ifconfig 
eth0 down', to 'unplug' the currently used wire.
- After 10 seconds (REAP timer expiry), probes are sent, the other 
possible path is identified thanks to REAP, and the ssh stream is 
switched to the other wire, with ssh still believing it is speaking to 
fec0::3.

The whole process can be followed watching /proc/net/shim6, and a packet 
sniffer on the host is very useful too.

As this only tests TCP (since ssh uses TCP), such exchanges may be tried 
also with other programs, using UDP or raw sockets.

I did not test it with different IPsec modes, because as a first 
simplifying assumption, i ignored IPsec.

>
> You should probably change the __barre_ texts to "#if defined 
> (CONFIG_SHIM6) || defined(CONFIG_SHIM6_MODULE)" and make the 
> appropiate options available through Kconfig and Makefile. And please 
> upgrade the code to the latest version of kernel source code. A crazy 
> idea: have you considered also if part of the SHIM6 could be somehow 
> integrated better into the XFRM architecture?
>
Thanks for these indications. I will take it into account. In fact the 
currently available version of my shim6 implementation is there since 
june 2006 (when I presented my Master's thesis). Then I had holidays 
until now, but my plan is now to :
- update it to kernel 2.6.17
- Make it loadable as a module
- remove the simplifying hypotheses I made during my Master's thesis : 
the big lack for now is HBA/CGA support, which i will add soon, but 
there is also user API (probably based on 
draft-sugimoto-multihome-shim-api-00), and various options described in 
shim6 proto draft.
- Prepare a more serious test suite in a real lab.

Note that I intend not only to update it from kernel 2.6.15 to 2.6.17, 
but also from draft proto-03 to proto-05.
About xfrm : It was simply ignored on the beginning, but yes, i will 
consider it.

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCL, Belgium