3. TCM projects |
Finland is technically a highly advanced country, and arguably boasts the most advanced public telecommunication systems in the world. It is also a leading country in software research and development. An additional advantage is lack of restrictions on development and use of cryptographic algorithms which restricts progress in other countries.
In 1995, Tech. Lic. Pekka Nikander initiated a project on network security at the Telecommunications Software and Multimedia Laboratory (TCM) at the Helsinki University of Technology (HUT). At the time there were no implementations of IPSEC outside the United States. Part of the project was to develop and study IPSEC prototypes which could later be implemented as functional software.
The initial works was done by Timo Aalto as part of his Master's Thesis. It involved a prototype of IPSEC under Solaris 2.5 OS using STREAMS mechanism. The project was continued by Santeri Paavolainen who set out to optimize and improve the code. In 1997 Bengt Sahlin tried a different approach, and developed a Conduits+/Java prototype. Also during 1996/97 a group of students designed a Macintosh version as part of the Tik-76.115 Individual Project course.
The first work concerning IPSEC in relation to the security project at the TCM laboratory was done by Timo Aalto who implemented IPSEC prototype using STREAMS under Solaris 2.5. This protocol was designed for IPv4 as an add-on to the existing implementations (this means that in this section reference to IP should be taken as reference to IPv4).
The purpose of the study was to build an IPSEC prototype and investigate its performance, portability, and possible extensions. The project has been based on the Requests For Comments (RFC), deployed by the IETF, as they were when it was started. Due to recent revisions, the original specifications have become somewhat outdated by now.
The use of STREAMS tries to assure that the code can be easily ported. However, objectively this may be hard to achieve, because it depends on existing TCP/IP implementations.
There are three ways to add the IPSEC to the IP protocol layer.
The diagram below presents the structure of this prototype. The architecture consists of a set of device drivers, a management module and interfaces between the subsystems:
The modularity of this design means that although only MD5 and DES-CBC are incorporated into this prototype, additional cryptographic transformation drivers can be added with ease (a cryptographic transformation driver is a module which encodes/decodes the data). The interface supports dynamic connections which saves resources.
The prototype implements manual key distribution which is OK for the purpose of testing this implementation. It is however possible to implement an automatic key distribution system and link it in if such need arises. Aalto stresses that it is crucial that IPSEC pays attention to the security of the keys on the host computer, otherwise the security gained through IPSEC may be lost.
The two diagrams below present the IPSEC control logic for incoming and outgoing traffic:
[outgoing]
[incoming]
The performance of Aalto's prototype was evaluated by transferring a large file using rcp command from SUN SPARCStation 4 to SUN SPARCStation 1+ using 10MB/s Ethernet as transmission medium.
| Performance Measurement Values | |
| No IPSEC, no STREAMS | 315 kb/s |
| STREAMS without use of queues or context switches, no IPSEC | 237 kb/s |
| STREAMS with queues and context switches, no IPSEC | 56 kb/s |
| IPSEC without AH and ESP | 47 kb/s |
| IPSEC with AH | 26 kb/s |
| IPSEC with transport-mode ESP | 26 kb/s |
| IPSEC with tunnel-mode ESP | 26 kb/s |
| IPSEC ESP-part AH and tunnel-mode ESP | 19 kb/s |
| IPSEC with transport-mode ESP and AH | 20 kb/s |
| IPSEC with tunnel-mode ESP and AH | 18 kb/s |
The use of STREAMS mechanisms for handling messages incorporating only the put routine decreases performance by about 25%. The use of streams queues and service routine decreases the performance by about 80%. The performance drop is due to a number of extra context switches. Additional delays are caused by copying data. Hence most of the processing time in this prototype is spent on STREAMS processing.
Aalto suggests several solutions to the performance problem. Performance improvements must be examined through objectives for the implementation. If the current objectives: security, portability and modularity, stay, the performance can be improved by avoiding the use of queue and context switch whenever possible. All the IPSEC can be done within the same context unless congestion occurs on one of the drivers. This requires more sophisticated flow control handling compared to the current implementation. Performance can be improved to approximately 180-200 kb/s.
It may be beneficial performance-wise to eliminate the use of multiple STREAMS device drivers, and to do all the IPSEC processing within a single device driver. The modularity may be then preserved by designing functional interfaces within the driver.
By dropping portability, we can further increase performance. This requires implementing IPSEC as part of the IP layer. In the future it might also be possible to use dedicated hardware to compute the transformations. This has an advantage of offering extra security, but reduces the flexibility of the system.
If you would like to examine the project in more detail, please look up the thesis from the link page.
Aalto's work was continued by Santeri Paavolainen who set out to optimize the STREAMS implementation. Paavolainen rewrote the code, and created ipsec2 which includes:
Unfortunately at this time performance figures for this implementation are not available. Description of the mechanisms used can be found on the links page.
The goal of Bengt Sahlin's project was to implement a prototype of IPv6 and IPSEC that is portable, reusable, and modular. An object oriented approach was taken and Java was chosen as the implementation language. The Conduits+ framework was chosen as an experimental framework for the implementation. The main emphasis was put on the implementation architecture, hence performance issues were considered only concerning architecture, not the prototype. IPv6 was implemented only in its minimal form to allow for testing IPSEC and manual key management was deployed.
Conduits+ is a framework for network software. It reduces the complexity of network software, makes it easier to extend or modify network protocols, and is sufficiently efficient. A key factor in designing reusable communication protocol software is how to factor out the common structure and behavior from the protocol specific parts. When using Conduits+, most of the control is the responsibility of the framework, and the programmer can concentrate on the environment.
We can list the advantages of using a framework:
Conduits+ is made up of two sorts of objects: conduits and information chunks. Information chunks are everything flowing through the conduits. A conduit is a software component with two distinct sides. These sides may be used to connect a conduit to another, neighbor conduit.
The use of the Conduits+ framework in this implementation of IPSEC provided a guarantee of modularity and reusability. Modularity is achieved because the framework allows additions to the existing software by simply building more conduits, and reusability is defined by the purpose of the framework.
The Java programming language was used as it helps fulfill the portability goal of the project. Any machine implementing the Java Virtual Machine can run Java byte code. Java also offers libraries with useful methods for protocol programming.
There are several other advantages in using Java. For more details please refer to Java documentation.
The prototype was implemented under Solaris 2.5. The Conduits+ framework and the IPv6-IPSEC parts are implemented in Java using the Java Development Kit (JDK). The Ethernet adapter is implemented in C (an ethernet adaptor is a software piece responsible for communicating between ethernet hardware and the protocol layer which uses it).
[A conceptual model of the implementation]
IPv6 has been designed to be simple, and hence the implementation architecture should follow the ideology. As little processing as possible should be done to regular IPv6 packets. Special processing, for instance the security transforms, is deferred to option headers that can be dynamically added. This means the architecture must be dynamic, and allow headers to be dynamically added to outgoing packets, and dynamically handled when receiving a packet.
As can be seen from the conceptual model, IPSEC has been implemented inside the IPv6, unlike Aalto's prototype where it was implemented below the IP layer. This illustrates how IPSEC is designed to be an integral part of IPv6, but is an add-on to IPv4. As Aalto pointed out, implementation inside the IP also improves the performance as some of the unnecessary communication between packages is cut out.
Performance was considered an issue only concerning the architecture, not the prototype. The JDK is not very mature and needs improvement.
The performance of the prototype was evaluated by sending variable amounts of data between two Sun SPARCStation 20 machines using 10Mb/s Ethernet as transmission medium:
[the test environment]
The table below shows results from the transmission tests:
| Block Size (bytes) | Ordinary IP (bytes/s) | Encrypted IP (bytes/s) |
| 1 | 14 | 7 |
| 10 | 135 | 69 |
| 100 | 1333 | 578 |
| 1000 | 11765 | 3571 |
| 10000 | 39526 | 14706 |
| 100000 | 91659 | 36928 |
| 1000000 | 149589 | 42876 |
Transmission speeds of up to 40kb/s with encryption (and 150kb/sec without encryption) have been achieved. This can be considered a reasonable performance for this unoptimized prototype. It should be possible to achieve much better results through simply by use of better, just-in-time Java compilers such as Kaffe.
Sahlin's conclusion is that Conduits+ is a good concept, and together with Java they seem to capture the flexible and dynamic nature of IPv6. There is scope for improvement within the framework itself to make the code more reusable. On final note we need to say that IPv6 is stateless, which causes a slight semantic problem as some of the functionality is implemented with the Conduits+ States. This means that perhaps Conduits+ is more suitable to protocols having many states, but definitely not restricted.
For complete discussion of this prototype, please refer to the Thesis by Bengt Sahlin, which can be found at the links page.
Secure Open Transport (SecOT) prototype has been developed as a topic for Tik-76.115 Individual Project. The purpose was to implement an IPSEC prototype for the Macintosh Open Transport environment. The UNIX STREAMS implementation was used as design basis, and Timo Aalto coordinated the project.
Apple Open Transport is the modern networking and communications subsystem for Mac OS. Open Transport is based on industry standards and brings a new level of networking connectivity, control, and interoperability to MacOS systems, while preserving and enhancing the hallmark of the Macintosh and MacOS - build-in support for easy-to-use networking.
Open Transport development was started with assumptions that networking is inherently a multiplication, multi-protocol proposition; and that the customers should not have to start over to achieve networking interoperability. This defined five key design goals:
The C programming language was chosen for this implementation. Only the essential features were built into this prototype. The STREAMS mechanism used also handles the minimum amount of STREAMS messages; those needed for supporting IPSEC. Although logically IPSEC is implemented between TCP and IP, it proved easier to build it between IP and the hardware layer.
Internally IPSEC has been divided into modules, which use procedures to communicate with each other. The transformation modules (used for coding and decoding the packets) were implemented in such a way that addition of new transforms could be done with minimum effort.
[Structure of the implementation]
The design allows the program to be totally transparent to the user, and only a drop in transfer speed indicates its presence. Unlike the other designs though, this project did not opt for portability. The development lead to a very specific interface to communications hardware which makes porting difficult.
The working principle of the design is very simple. The control module for IPSEC resides between IP and the Ethernet driver. When IP sends a packet, the control module checks what kind of security policy there should be, applies the authentication or encryption (or both) to the packet, and forwards it to the Ethernet driver. Similarly upon receiving a packet from the Ethernet driver, it is validated by the transformation modules, and if it passes it, it is forwarded to the IP layer.
Upon any error (such as bad authentication/encryption and other) the packet is automatically discarded.
Despite a close working relationship with the Macintosh hardware, the code has been written in a way that would allow further development. The division of code into functional modules allows porting and modifications by upgrading or changing separate modules rather than a need to rewrite everything from scratch. It also allows a fairly easy way to add new modules, for instance better transforms.
A complete description of each of the modules of this prototype can be found from the project web page. The link page provides a link.
Because MacOS is currently a single-user operating system, there is no need for concern about security of keys on the host machine itself **.
At the time of the design, only manual key configuration was considered, hence this implementation (like the ones described earlier) needs manual key configuration, and is designed to work in small, static test environments. The testing was performed between two PowerMac 7200 machines.
The prototype was always tested as an entire package, not by single module performance.
Three different ways were used to test the working of the prototype:
Testing was done according to the following procedure:
Performance (speed-wise) of this prototype has not been tested.