Security Project at the TCM Laboratory
Table of Contents |
1. Introduction
2. IPSEC
3. TCM projects
4. Links (separate document)
1. Introduction |
The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. It provides for transmitting blocks from sources to destinations which are identified by fixed length addresses. The protocol is specifically limited in scope to provide the functions necessary to deliver a datagram from source to destination, and there are no mechanisms for other services commonly found in host-to-host protocols.
In recent years the Internet has experienced dramatic growth rate. Large organizations, small companies, and private people alike are joining in every day. This has brought forth two critical issues concerning the current implementation of the Internet Protocol - the IPv4 - security and availability of addresses.
IPv4 relies on 32bit addressing scheme which was sufficient when IPv4 was deployed. Recent growth however, has put a strain on the address space, and a new addressing scheme is needed. As this is not an immediate concern, and short-term solutions to prolong the availability of addresses have been deployed while waiting for transition to a new version of the protocol which will allow 128bit addressing (IPv6).
A more urgent problem, however, is data security, or actually the lack of it. In its growth, the Internet started attracting not only academic circles and research labs, but also banking, commerce, and business. It is a growing market area which is yet to be exploited to its full potential. The lack of security is a rather crippling factor. IPv4 does not provide measures which would assure that the data being received by the end station has not been altered during the transmission, or that it actually came from the claimed source. Bank transactions can be altered, credit card numbers can be stolen, false data can be fed to companies, and so on. The most often found current practice is the use of application layer security. This however, does not protect from all forms of attack, and does not encourage standardization.
In order to enforce security in the existing systems, many companies hid themselves behind firewalls. These are systems which stand between a LAN (which is considered to be a trusted network), and the cruel world outside. Firewalls attempt to analyze the incoming packets of information and determine if they contain valid information. This might seem good, but it restricts access to the outside from within the LAN.
Because of the need for an upgrade anyway, it was logical that the new version of the Internet Protocol - IPv6 - should contain a native security system which would allow the users to communicate securely. At the same time, it must be realized that because the Internet is a vast and complex network, the transition to the new version of the protocol will not be immediate, and hence the security implementation should be such that it would be compatible, and adaptable to IPv4.
Internet Engineer Task Force (IETF) has agreed on a set of rules which would define security measures in IPv6, and has gathered them under the name IP Security (IPSEC).
2. IPSEC - Internet Protocol Security |
IPSEC focuses on the security that can be provided by the IP-layer of the network. It does not concern itself with application level security such as PGP for instance.
We can divide the security requirements into two distinct parts:
The Authentication Header (AH) is a mechanism for providing strong integrity and authentication for IP datagrams. It might also provide non-repudiation*, depending on which cryptographic algorithm is used and how keying is performed. The security is provided by adding authentication information (to the IP datagram) which is calculated using all of the fields in the IP datagram (including not only the IP header but also the other headers and the user data) which do not change in transit (for instance hop-count field in IPv6, and time-to-live field in IPv4, headers cannot be included as they are altered at each relay the datagram passes through).
To no surprise this system provides much more security than the current bare version of IPv4. Authentication might actually be sufficient for some users who do not require confidentiality. The argument for not using more security measure for some types of packets is the processing costs associated with computation of authentication data by the participating end systems. The authentication data is carried in its own payload, hence the systems which are not participating in the authentication may ignore it.
When used with IPv6, the AH is normally placed after the Fragmentation and End-to-End headers, but before the ESP and transport-layer headers (TCP or UDP for example). In IPv4, AH is placed immediately following the IPv4 header. Below are some examples of the IP header structures with and without the AH:
[Authentication Header example when used with IPv4]
[Authentication Header example when used with IPv6]
[Authentication Header tunnel mode positioning for typical IPv4 and
IPv6 packets]
IPSEC provides confidentiality services through Encapsulating Security Payload (ESP). ESP can also provide data origin authentication, connectionless integrity, and anti-reply service (a form of partial sequence integrity). Confidentiality can be selected independent of all other services. There are two modes for providing confidentiality using ESP. One is transport mode, and the other is tunnel mode. Tunnel mode encapsulates an entire IP datagram within the ESP header. Transport mode, encapsulates the transport layer frame inside ESP (the term 'transport mode' should not be misconstrued as restricting its use to TCP and UDP).
When incorporating the ESP into the IP system (IPv4, IPv6, or Extension) the protocol header immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6) field.
Below are some examples how the typical IPv4 and IPv6 packets might look before and after applying ESP - transport mode:
And an example of tunnel mode:
A SA normally includes the following parameters:
[required]
All hosts claiming to provide IPSEC services must implement the AH with at least the MD5 algorithm using a 128-bit key as specified in the AH RFC. An implementation may support other authentication algorithms in addition to keyed MD5. All ESP implementations must support the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) mode as detailed in the ESP specification. Other cryptographic algorithms and modes may also be implemented in addition to this mandatory algorithm and mode. MD5 and DES-CBC should be set as default algorithms.
Although this is arguably the most secure method to distribute keys, and the simplest one, it does not scale, and only works in very small, static systems. It can be used for LANs and some firewall systems, but is a short-term approach.
Work is currently under way to provide a secure, and efficient method for automatic key distribution. For more details please visit IETF web site.
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 work 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.
* non-repudiation - The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data.
** as we can recall, Aalto put emphasis on the security of keys on the host machine because his implementation was designed to run in a multi-user environment.