Standards, IPSEC and the encryption penalty
By Joel Snyder
Most of the products we looked at have proprietary encapsulation and key management schemes, but vendors are planning to have open and interoperable tunnels available soon after the relevant standards are . The Internet Engineering Task Force Working Group on IP Security Protocol (IPSEC) for encrypting tunnels and key management.
Most encrypting tunnel vendors will have to support three developing standards: Encapsulating Security Payload (ESP) and Authentication Header (AH), which discuss how a tunnel and its administrative information is sent through IP, and Internet Security Association and Key Management Protocol (ISAKMP), which describes how keys are exchanged and tunnels are created and managed.
ESP and AH were sent out as ``last call'' standards on Oct. 3; this indicates they're very close to completion. Once ESP and AH are standardized, tunnels from different vendors will be able to communicate. However, key exchange and management will have to be handled manually.
A good starting point to learn more about the ongoing work is at the IPSEC working group home page.
One of the problems with IPSEC's encapsulation approach is that it makes each IP packet larger after encryption, because additional header information is added to each one. Increasing the size of packets can be a serious performance problem when packets as long as the maximum transmission unit (MTU) of the LAN must be encrypted might be with a browser downloading a graphic or long page. When a maximum length packet is expanded beyond the MTU, it must be fragmented into two (or more) packets. This the load on the routers and wastes a significant amount of bandwidth.
There is no easy solution to this problem. Although it is possible to adjust the TCP/IP stack on each workstation to send packets slightly shorter than the MTU of the LAN, not every TCP/IP stack is so accommodating. Even worse, keeping these mutated stacks under control could be a full-time job, especially given the dynamic nature of Microsoft's TCP/IP software.
Encrypting tunnels do not use the IPSEC protocol can Encrypt in Place (EIP), which generally does not cause packet fragmentation. This benefit comes at a cost, though: EIP tunnels are all proprietary. A few vendors' products, such as Data Fellows Inc.'s F-Secure VPN with SSH, Microsoft with Point-to-Point Tunneling Protocol, and Technologic, Inc. Interceptor with Simple Key Management for IP (SKIP) have chosen other open approaches rather than the IPSEC route.
To see the , we ran our performance tests twice: once with normal MTUs on the test systems, and again with MTUs slightly smaller than the maximum, which would tend to let us avoid packet fragmentation.
The differences were striking. For EIP tunnels, such as Cisco's IOS, performance MTU was the same or slightly better than MTU. For IPSEC-style tunnels, a slowdown of 10% or more was obvious in many systems.
How to Advertise | Copyright