INET Conferences

Study from Hybrid Implementation of SwIPe and IPsec

Masanori FUJIE <fujie@iij.ad.jp>
Jun-ichiro ITOH <itojun@itojun.org>
Takashi TOCHIHARA <tochi@iij.ad.jp>
Hiroo SHIRASAKI <sirasaki@iij.ad.jp>
Kazumasa UTASHIRO <utashiro@iij.ad.jp>
Internet Initiative Japan Inc.
Japan

Abstract

IPsec is quickly becoming the standard protocol for secure communications over the Internet. Prior to the adoption of IPsec, the swIPe protocol had been widely used for IP-level security, but because of incompatibility between these two, there are now many problems that must be faced in migrating to the new protocol. This paper describes a method of hybrid implementation that can be used to achieve smooth transition from swIPe to IPsec without compromising secure connectivity between hosts.

Contents

• Introduction
• Motivation
• Transition from swIPe to IPsec
• Implementing a hybrid protocol system
• Security protocol translation gateway
• Evaluation
• Status of the implementation and lessons learned
• Conclusion
• Acknowledgments
• References

Introduction

Numerous studies have been and continue to be made on protocols for achieving secure communications on the Internet. There are two major published protocols dealing with IP layer security: swIPe[1] [2] and IPsec[3]. Until recently, swIPe was widely used, but IPsec is slated to become the standard protocol for secure communications, and many IPsec-based products are now available commercially.

SwIPe and IPsec, however, have no mutual compatibility, and it will not be easy for a site which already uses swIPe on its network to shift to IPsec, especially when communicating with other organizations via secure connections. The solution we propose to this problem is to implement into the UNIX kernel a hybrid system which supports both protocols, thereby facilitating a smooth transition from swIPe to IPsec. A similar mechanism and transition can be applied to three or more different protocols.

In this paper, we discuss issues related to hybrid implementation of two protocols and present examples of methods for migrating from a swIPe-based network to an IPsec-based one. Finally, we discuss the lessons learned from our experience.

Motivation

Before the proposal of IPsec by the IP Security Working Group of the Internet Engineering Task Force (IETF), swIPe was in extensive use and in fact had become the de facto standard for IP layer security protocols. However, now that IPsec has been adopted as the standard track protocol for secure communications at the IP level, the need to switch from swIPe to IPsec in the near future is apparent.

Our company installs firewalls and gateways on customer sites with modified swIPe implementation that is capable of effecting a swIPe-tunnel. Customers utilize the virtual circuit provided by the swIPe-tunnel for secure communications with their branch offices, trading partners, and customers. As the use of IPsec becomes more widespread, however, our customers will need to effect secure communications not just with existing swIPe sites, but with IPsec sites as well.

Nevertheless, a number of our customers may not be able to drop swIPe support in the foreseeable future because some of their peer sites and hosts may not migrate to IPsec at all. Thus, any transition can only be achieved gradually, and care must be taken to ensure minimal interruption of service at related sites. It is unrealistic to expect all swIPe firewalls and gateways in the world to make this changeover simultaneously, so effecting a smooth transition from swIPe to IPsec necessitates a system capable of handling both protocols simultaneously.

Furthermore, there are at present two versions of IPsec specifications in wide circulation: old IPsec as specified in RFC 1825, and new IPsec[4], which is currently being discussed by the IPSEC Working Group. But these two protocols are not compatible with one another, and even though the new IPsec will make the old one obsolete, networks utilizing old IPsec will undoubtedly be around for some time.

Thus, as is evident, a similar problem exists for the transition from old to new IPsec; here, too, a multiple-protocol system will provide a good solution.

Transition from swIPe to IPsec

In this section we will present a model illustrating the phases involved in the smooth transition of security protocols, using the transition from swIPe to IPsec as an example. By analogy, this scenario can be applied to transitions between other protocols, such as that from old IPsec to new IPsec.

Figure 1-a shows a typical situation: the two sites using swIPe gateways are able to effect secure communications. When a packet is sent from site A to site B, it is encrypted at the gateway GW-A and decrypted at GW-B. Under this configuration, however, it is impossible for site C, which uses IPsec, to effect secure communications with either of the other two sites.

Fig. 1-a. IPsec site cannot effect secure communications with swIPe site

In Figure 1-b, our hybrid protocol system has been implemented on Site A. The swIPe/IPsec gateway GW-A uses swIPe for packets going to and from GW-B, and IPsec for packets to and from GW-C.

Fig. 1-b. Secure communications between swIPe sites and IPsec sites via a hybrid protocol system

In Figure 1-c, site B upgrades its gateway to an IPsec-compliant one. Site A now uses IPsec for communicating with either of the other sites, and sites B and C are able to communicate directly. GW-A is able to drop swIPe support at any time.

Fig. 1-c. IPsec is used for secure communication between all three sites

The basic premise remains the same even for swIPe and IPsec hosts, rather than gateways. The scenario is, however, dependent upon a hybrid protocol system that is capable of handling both swIPe and IPsec.

Implementing a hybrid protocol system

The original swIPe protocol stack implementation by Ioannidis and Blaze works on SunOS 4.x, which is a 4.3BSD variant. This implementation supports only host-to-host encryption, which is referred to as transport mode in IPsec terminology. We have ported this transport mode into BSD/OS 3.x, a 4.4BSD-Lite2 variant, and have also written additional code to support tunnel mode.

For supporting IPsec in the same manner as swIPe, the IPsec protocol stack is implemented into a swIPe-capable kernel. An overview of our security protocol stack is shown in the figure below.

Fig. 2. Security protocol stacks

The swIPe, old IPsec, and new IPsec protocol handlers are completely independent, and the program code for each is clearly separated. It is therefore possible to easily remove one, two, or all of the security protocol stacks from the kernel. For example, to create a kernel with all protocol stacks, add the following lines to the kernel configuration file:

options CRYPTO          # for common routines for SWIPE and IPsec
options SWIPE
options IPSEC_NEW
options IPSEC_OLD

To drop swIPe support, you need only remove the "options SWIPE" line from the configuration file.

Low-level functions for cryptographic operations, such as DES crypto and MD5 hash, are common to swIPe and IPsec stacks. Our implementation shares these functions in both stacks. We have also integrated swIPe-tunnel routines with IPsec-tunnel routines, and they are implemented as a general IP-over-IP tunneling mechanism.

To manage the secret key used for per-packet encryption, swIPe and IPsec need a key database implemented in the operating system kernel. SwIPe used the concept of a policy to describe a secure connection. The policy table entry contains the IP address of the remote host, as well as other elements such as algorithms for encryption or authentication. We modified the policy table when we merged the swIPe tunnel-mode support into the original swIPe code.

On the other hand, IPsec utilizes the concept of security association. Security association is identified in the Security Parameter Index (SPI) and each entry contains the IP address of the remote host, algorithms for encryption or authentication, and other related information.

The following table shows the comparison between entries of swIPe's policy table and IPsec's security association table.

swIPe policy table entry		IPsec security association table entry
original(transport-mode)	modified(transport/tunnel-mode)
Destination IP address	Destination IP address/masks	Destination IP address/masks
Destination IP address	Source IP address/masks	Source IP address/masks
Policy identifier		Security Parameter Index
Authentication algorithm		Authentication algorithm
Authentication Keys		Authentication Keys
Encryption/Decryption algorithm		Encryption/Decryption algorithm
Encryption/Decryption Keys		Encryption/Decryption Keys
Sequence Number		Incremental counter for replay prevention
--	mode (tunnel or transport)	mode (tunnel or transport)

Obviously, the two tables contain several similar fields. To ease management of both tables, we have integrated the swIPe policy table into the IPsec security association table and have mapped fields in the swIPe policy table to their corresponding field in the IPsec security association table. Both swIPe and IPsec then use this same table as their security association database. An integrated table entry is composed of the following values:

Integrated table entry
Destination IP address/mask
Source IP address
Security protocol (whether swIPe or IPsec)
Security Parameter Index
Authentication algorithm
Key for authentication
Encryption/Decryption algorithm
Key for Encryption/Decryption
Incremental counter for replay prevention
mode (tunnel or transport)

The "security protocol" field is used to identify three security protocols: swIPe, old IPsec, and new IPsec. For example, if the security protocol field indicates the use of new IPsec, IP packets relevant to the table entry are passed to the new IPsec processing engine. Other security protocols can be stipulated by their inclusion in this field. In the above description, IPsec is treated as a single protocol stack, but old and new IPsec are in fact managed separately.

When the kernel sends an IP packet to ip_output(), the security association table is referred to using the destination IP address as a key. If a matching entry is found in the table, the appropriate security protocol -- swIPe, old or new IPsec, or none -- will be chosen based on the security protocol field, after which the packet is sent to the appropriate output routine:

        { swipe_output(), oldah_output(), oldesp_output(), ah_output(), esp_output() , ip_output()}

After the packet has been processed by the specified output function shown above, ip_output() is called with a process completed flag at its final stage. The packet is then sent to the output interface.

When the kernel receives an IP packet in a protocol input routine, the security association table is referred to using the source IP address, the security protocol as indicated by the next protocol field in the IP header, and -- in cases where the packet is processed with Ipsec -- the value of the Security Parameter Index. If a matching entry is found on the table, the packet is sent to the appropriate input process routine:

        { swipe_input(), oldah_input(), oldesp_input(), ah_input(), esp_input(), proto_input()}

After the packet is processed by the specified input function, it is sent to the process routine of the next protocol.

Specifications for IPsec have long been under development, and there are several versions of IPsec -- such as the RFC version -- which were published a long time ago, as well as Internet-Draft versions, which reflect recent discussion. There are some differences in the protocol header format, and because there is no field in the AH[5][6] or ESP[7][8] headers which indicates the version, we were forced to distinguish different versions of the protocol based on the protocol entry of the security association table. Once the older version becomes obsolete, however, we can easily detach the old processing function.

The controlling API between the kernel and userland is also integrated for both protocols. Therefore, there is no need to rewrite userland programs even when we introduce new security protocols.

Also, since the userland tools for administrators are common to the supported security protocols, the administrators need not learn any new management operations. They need only to add an option for specifying which security protocol is to be used, as follows:

sleconfig setlink 192.168.4.168 192.168.4.194 swipe \          # swIPe
                des SecretKey auth AuthenticationKeysleconfig setlink 192.168.4.168 192.168.4.194 ipsec old_ah \   # old IPsec
                transport 1000 hmacmd5_128 AuthenticationKey
sleconfig setlink 192.168.4.194 192.168.4.168 ipsec old_ah \
                transport 2000 hmacmd5_128 AuthenticationKeysleconfig setlink 192.168.4.168 192.168.4.194 ipsec esp \      # new IPsec
                transport 100 des SecretKey
sleconfig setlink 192.168.4.194 192.168.4.168 ipsec esp \
                transport 101 des SecretKey

The number included in the transport mode description represents the SPI. It is also possible to specify hmac-sha1[9] as an authentication algorithm and Triple DES or CAST as an encryption algorithm. Once IPsec is deployed throughout the Internet, the default security protocol may be changed to IPsec by updating the administration tools.

In summary, hybrid implementation offers many advantages. The integrated association table allows a choice of security protocol in order to match the protocol supported by the peer. A host with hybrid implementation can effect secure communications with both swIPe hosts and IPsec hosts simultaneously. The integrated association table is carefully designed to allow easy integration of future security protocols. The user interface and programming API are common to both protocols. Administrative differences are minimal, reducing the difficulties associated with transition. In the design of the user interface, a "least surprise" philosophy was emphasized in order to help administrators learn about the new features. The implementation separates swIPe and IPsec nicely, while sharing common low-level libraries.

Security protocol translation gateway

We also implemented a security protocol translation gateway by modifying the hybrid implementation.

For example, in cases where secure communications are to be effected between swIPe host A and IPsec host B, a lack of compatibility means that without the use of a translation gateway, host A would have to be modified to support both swIPe and IPsec, as shown in Figure 3.

Fig. 3. No translation gateway

By using a translation gateway, the IPsec host can effect a secure connection with the swIPe host, and vice versa, without the end hosts requiring any modification. Fig. 4 shows swIPe host A and IPsec host B communicating via the translation gateway host C. Please note that host A implements only swIPe, and host B implements only IPsec in this example.

Fig. 4. With a translation gateway

In this situation, it is assumed all three hosts (A, B and C) trust one another. Host C is then entrusted with the encryption keys for host A and host B, as well as other information.

Transport-mode security protocol ordinarily assumes that a packet is to be decrypted only at its final destination. A translation gateway (in this case, host C) is specially configured, however, to decrypt and re-encrypt the packet when relaying it between A and B, even though the packet is not intended for host C. Host A will transmit a transport-mode swIPe packet to host B, and host C will relay the packet.

For example, host C has the following security association table. The first two columns are related to inbound packets, the following two columns to outbound ones.

Security association table on host C

	Inbound	Inbound		Outbound	Outbound
Source address	host A 192.168.21.2	host B 172.16.31.3		host A 192.168.21.2	host B 172.16.31.3
Destination address	host B 172.16.31.3	host A 192.168.21.2		host B 172.16.31.3	host A 192.168.21.2
Protocol	swIPe	IPsec-ESP		IPsec-ESP	swIPe
Algorithm	-	DES		DES	-
Key	swipe-1	ipsec-2		ipsec-2	swipe-1
SPI	-	100		200	-

When host C receives the packet, it refers to the security association table shown above, based on the packet's source and destination addresses. If the received packet is from host A to host B, host C refers to the information in the first column of the table. This tells host C to process and decrypt the packet using swIPe. Host C then refers again to this security association table when the packet is forwarded, this time using the information in the third column of the table. This tells host C to process and encrypt the packet using IPsec-ESP. Packets sent from host B to host A by way of host C are processed in a similar fashion.

Thus, the implementation of a security protocol translation gateway between two hosts will allow them to seamlessly effect secure communications even though they do not share a common protocol.

Evaluation

The hybrid protocol system as described above was implemented on a BSDI BSD/OS 3.0 kernel, and the results of its performance were measured on a PC-AT compatible computer with a 200MHz Intel Pentium processor using a 56 byte ICMP packet.

The processing time of the ip_output() routine as well as that of the cryptographic routine was measured on various stacks such as a BSD/OS 3.0 plain stack, our swIPe stack on BSD/OS 2.1, and a swIPe/IPsec dual stack on BSD/OS 3.0. SwIPe was originally implemented on BSD/OS 2.1, and IPsec was developed on BSD/OS 3.0. The integration was done based on the IPsec protocol stack and works on BSD/OS 3.0. Therefore the OS versions for the swIPe and hybrid implementation are different.

The result shows that the cost of sending a packet consists mainly of the ip_output() and cryptographic processing for the packet. The time required to refer to the table is almost the same for either a swIPe stack or an integrated dual stack. Thus we feel that hybrid implementation does not adversely affect performance.

The table below shows that the cost of IP protocol handling is almost the same in any of the three cases. This shows that the addition of the security protocol to the kernel does not have a negative impact on the performance of IP protocol handling. Also, the cost of the execution for a cryptographic routine is the same as that for a swIPe single stack and dual stack.

In these implementations, we used our own DES routine called IIDES[10], which demonstrates very good performance. In the swIPe and IPsec implementation, DES crypto is not much slower than MD5. Thus it can be said that IIDES code helps efficient computation of DES crypto in this situation. RTT is measured between the hosts on the same Ethernet network.

Kernel Output Processing Time for Hybrid Implementation (usec)

Implementation		ip_output() process time	crypto module process time	table lookup time	RTT(ms)
plain BSD/OS 3.0		97.79	--	--	0.798ms
swIPe on BSD/OS 2.1	NULL	97.08	--	--	--
	swIPe	297.09	MD5+DES: 142.48	57.54	1.408ms
dual stack on BSD/OS 3.0	NULL	99.66	--	--	--
	AH	209.71	MD5: 62.21	47.85	2.194ms
	ESP	229.36	DES: 84.95	44.76	2.230ms

We also performed interoperability tests with other implementations. The hybrid implementation is confirmed to be interoperable with the following implementations: Yokogawa IPsec, WIDE hydrangea IPv6/IPsec[11], YAMAHA experimental IPsec on RT100i dialup router[12], original swIPe implementation, and TIS swIPe and IPsec implementation[13].

Status of the implementation and lessons learned

The current implementation supports most standardized, cryptographic transformations, such as DES-CBC[14] [15], Triple DES[16] [17], CAST128[18], HMAC-MD5[19][20], HMAC-SHA1[9], and so forth. We plan to merge other transformations, such as MISTY1[21], in the future.

Current implementation of the security association table uses IPv4 addresses, i.e., struct sockaddr_in, as lookup keys. We will need to use struct sockaddr rather than sockaddr_in for supporting IPv6 addresses and various other address families. This is simple to implement and will make the security association table independent of address families. At this moment, the implementation controls the use of security protocols on a per-IP-address basis. A per-socket control mechanism is required to conform to the simple IPsec API[22] proposed by McDonald.

Although the specifications for IPsec have been under discussion at the IETF for a long time, the specifications are as of yet not fully established. While implementing the IPsec stack, we have noted that it would be better if the IPsec protocol included a protocol version field to enhance the classification of old RFC 1825 IPsec packets, new IPsec packets, or those of any forthcoming versions.

We also noted that it would be better to establish a common function call interface for cryptographic functions in the kernel. What is needed is a small, portable, and efficient function call interface standard. There have been several attempts by userland programs, but we think that they are too rich for use in the operating system kernels.

Conclusion

While swIPe has been widely used until now, and was in fact the de facto standard for security protocols, IPsec is increasingly being deployed as the standard protocol for secure communications on the Internet. To help smooth the transition from swIPe to IPsec, we have implemented a hybrid protocol stack for swIPe and IPsec in a BSD4.4-Lite2-based kernel.

In this paper we have discussed how swIPe and IPsec were implemented in a single kernel and this implementation's effect on processing performance. Performance measurement shows that the hybrid implementation discussed in this paper has no performance penalties over the original protocol stack implementation. We also discussed a swIPe/IPsec translation gateway based on our hybrid implementation.

As more attention is devoted to secure IP connections over the Internet, more and more products are developed in conformance with swIPe or IPsec standards. Although many swIPe-, old IPsec-, and new IPsec-compatible hosts are now in operation on the Internet, these three major protocol specifications have in fact no mutual compatibility. Our hybrid protocol implementation can be used for interoperation between them and will help smooth transitions from one standard to another.

Acknowledgments

The authors would like to thank members of WIDE Project for performing interoperability tests with us.

References

1. John Ioannidis and Matt Blaze: "The Architecture and Implementation of Network-Layer Security Under Unix," Proceedings of USENIX Security Symposium, Santa Clara, CA. (October 1993)
2. John Ioannidis and Matt Blaze: "The swIPe IP Security Protocol," IETF Internet Draft (1993)
3. R. Atkinson: "Security Architecture for the Internet Protocol," RFC 1825. (1995)
4. Stephen Kent and Randall Atkinson: "Security Architecture for the Internet Protocol," IETF Internet Draft. (1997 work in progress)
5. R. Atkinson: "IP Authentication Header," RFC 1826. (1995)
6. Stephen Kent and Randall Atkinson: "IP Authentication Header," IETF Internet Draft. (1997 work in progress)
7. R. Atkinson: "IP Encapsulating Security Payload (ESP)," RFC 1827. (1995)
8. Stephen Kent and Randall Atkinson: "IP Encapsulating Security Payload (ESP)," IETF Internet Draft. (1997 work in progress)
9. C. Madson and R. Glenn: "The Use of HMAC-SHA-1-96 within ESP and AH," IETF Internet Draft. (1997 work in progress)
10. H. Tachibana and H. Shirasaki and K. Utashiro: "IIDES IIJ Data Encryption Suite," Internet Initiative Japan Inc., ftp://ftp.iij.ad.jp/pub/IIJ/dist/IIDES/
11. WIDE IPv6/IPsec team Web page, WIDE Project, http://www.v6.wide.ad.jp/.
12. RT100i Web page, YAMAHA Corporation, http://www.rtpro.yamaha.co.jp/RT100i/
13. Gauntlet Web page, Trusted Information Systems Inc., http://www.tis.com/prodserv/gauntlet/vpn/
14. P. Metzger and P. Karn and W. Simpson: "The ESP DES-CBC Transform," RFC 1829. (1995)
15. C. Madson and N. Doraswamy: "The ESP DES-CBC Cipher Algorithm With Explicit IV," IETF Internet Draft. (1997 work in progress)
16. P. Karn and P. Metzger and W. Simpson: "The ESP Triple DES Transform," RFC 1851. (1995)
17. P. Metzger and W. A. Simpson: "The ESP Triple DES Transform," IETF Internet Draft. (1997 work in progress)
18. R. Pereira and G. Carter: "The ESP CAST128-CBC Algorithm," IETF Internet Draft. (1997 work in progress)
19. M. Oehler and R. Glenn: "HMAC-MD5 IP Authentication with Replay Prevention," RFC 2085. (1997)
20. C. Madson and R. Glenn: "The Use of HMAC-MD5-96 within ESP and AH," IETF Internet Draft. (1997 work in progress)
21. H. Ohta and M. Matsui: "A Description of the MISTY1 Encryption Algorithm," IETF Internet Draft. (1997 work in progress)
22. D. L. McDonald: "A Simple IP Security API Extension to BSD Sockets," IETF Internet Draft. (1997 work in progress)