The IPSec Standard

IPSec is the standard for protecting traffic at the packet level, using transforms�"-that
is, changes to the packet structure�"to confer security. There are two main transforms
used in IPSec: an Authentication Header (AH) transform and an Encapsulating Security
Payload (ESP) transform. The transforms are configured in a data structure called
a Security Association (SA).
The AH provides authentication (data origin authentication, connectionless
integrity, and antireplay protection) to a datagram. It protects all the data in the datagram
from tampering as specified in the Security Association, including the fields in
the header that do not change in transit. However, it does not provide confidentiality.
An AH transform calculates or verifies a Message Authentication Code for the datagram
being handled. The resulting MAC code is attached to the datagram.
Before a secure session can begin, the communicating parties need to negotiate the
terms for the communication. These terms are those defined in the SA. There needs to be
an automated protocol to establish the SAs to make the process feasible for the Internet
(that is, a global network). This automated protocol is the Internet Key Exchange (IKE),
which is meant for establishing, negotiating, modifying, and deleting SAs. IKE combines
the Internet Security Association and Key Management Protocol (ISAKMP) with the
Oakley key exchange. Oakley is a working group defining key exchange procedures.

The IPSec engine performs AH transforms,
ESP transforms, compression transforms, and special transforms (for example,
network address translation using IP4). Special transforms also include content- or
context-sensitive filtering and automatic fragmentation, if a packet exceeds the maximum
transfer unit size. The engine also has to detect denial-of-service attacks.

IPSec can be implemented in the handset, in a Node B, in a radio network controller,
and in intermediate routers in the IP network, including firewalls. IPSec, however, can
imply significant overheads in terms of delay and delay variability, processor overhead,
memory overhead, and additional transmission bandwidth requirements—the cost
of security. This is okay if there is a perceived value gain greater than the additional
cost. IPSec performance and the performance of processes such as the Diffie-Hellman
exchange can be very dependent on good software implementation—assembler
optimization, for example. By implication, it becomes a very intimate part of the QoS
SLA. A firewall on its own can introduce 150 ms of delay.
The problem becomes more acute if you need to dynamically authenticate a workgroup
with users joining and leaving during a session or in multicasting. To quote from
an Internet draft (www.ietf.org/internet-drafts/draft-ietf-ipsec-gkmframework-01.txt):
“The complexity of these [multicast] cryptography solutions may point to the application
layer being the best place for them to be implemented.” In other words, because
you need flexibility—that is, you cannot predict when users will be joining or leaving
the simulcast or multicast—it is better to implement security in the application layer.