IPSEC - TCM projects

3. TCM projects

3.5 SecOT - IPSec-on-Macintosh

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.

3.5.1 Open Transport

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:

Open Transport must protect customer and developer investments in existing network infrastructure and applications.
Open Transport must be based on existing cross-platform industry standards.
Open Transport must provide users with an easy to set-up, easy to use abstraction of the underlying complexity of multi-protocol networking.
Open Transport must also provide a complementary abstraction of networking and communications services for applications developers.
Open Transport must offer a flexible run-time model - one that lets a specific protocol be configured and selected at run time, rather than linked and compiled

All these are important aids in implementing IPSEC into Open Transport. Adding IPSEC should not require the developer to reorganize the network in any way. It should be easy to set up so that the transition to secure networking is not obstructed. Abstractions of networking and communications services provide a framework for developers onto which they can build. The dynamic nature also suits IPSEC well, as one does not need to pre-determine the use of the protocol.

3.5.2 Implementation

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]
Structure of the design of SecOT

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 ^**.

3.5.3 Results and performance

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:

Packet handling was tested using internal debugging. This dumped the contents of memory (using hexdump) directly to a local file so that the packets could be inspected before and after transforms.
A sniffer program was used to test the proper form of outgoing packets by comparing the sniffed ones with preset specs. This testing procedure is very close to the programmer's debugging tool, and assures that the prototype does not modify the packet between the hexdumping and sending.
Finally the prototype was tested against itself between two PowerMac machines. A daemon was installed on one of the machines, and the second computer tried to make contact. The advantage of this in respect to NRL testing is that the software does not need to be fully functional yet, as the program communicates against itself, and only uses the ready parts.

The program could also be tested against a reference implementation (Navy Research Laboratory - NRL), but this requires that it is already fully functional. This test should fully assure that the program is working properly and to specs.

Testing was done according to the following procedure:

Setting up the testing configuration
The clock was started
A large file was transfered using FTP
The clock was stopped
The transfer speed and elapsed time was used to compute the performance.

A total of 30 different test cases were used. A writeup of the tests and results can be found from the project page.

Performance (speed-wise) of this prototype has not been tested.

** 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.

Marcin Dobrucki, 1997