How can we achieve security?
Encrypting data is the obvious answer.

Where is the data being encrypted?
Usually the data is encrypted in application level or in the IP stack. IP stack schemes take a shotgun approach to encryption: They encode everything on a given link. But this all-or-nothing approach can take a big bite out of performance. Application-level encryption is the alternative. The advantage to the application-level approach is that net managers can decide what they want to encrypt and what they don’t want to. The downside is that encryption parameters have to be set up for each application. This is time consuming in and of itself.

How is the data being encrypted?
The data is being encrypted using well-tested encrypting algorithms. The two most common schemes use 56- and 128-bit keys. Most security consultants consider 56 bits the bare minimum for adequate protection. That's bad news for corporate networkers with global sites: The U.S. government typically allows only products based on skimpy 40-bit keys to be exported.

What kind of key has been used to scramble and decode the data?
Private-key mechanisms rely on one key that has to be exchanged and kept secret: a security headache in itself, as well as a management migraine. With private-key products everyone on the network is assigned his or her own secret key (see Figure 1). If two people want to share encrypted data, they must first exchange keys--with all the attendant risks. This can be a real damper on communication. The big issue here is keeping the key from falling into the wrong hands. Corporate networkers who don't want to spend their days playing post office or phone tag can set up a server to distribute private keys. This is the approach used by Kerberos, the famed security system developed by the Massachusetts Institute of Technology (MIT, Cambridge). The catch here is that putting all the private keys on a server gives hackers an obvious target. But using Kerberos is mind-numbingly complicated.
Public-key cryptography uses two keys: One is available to all; the other is kept confidential. Using two keys sounds twice as complicated, but it has a simple goal: Eliminate the need for end-users to exchange private keys. Do this, and a potential security breach is blocked.Whitfield Diffie and Martin Hellman developed public-key cryptography in 1976 at Stanford University (Palo Alto, Calif.) Their scheme uses logarithms over finite fields to secure and unscramble data. These days, about 70 percent of the public-key products on the market rely on RSA's Public Key Cryptosystem, which is licensed by a number of vendors. The RSA scheme factors large numbers into prime numbers. While public-key cryptography solves one big problem it introduces another. There's a lengthy handshaking procedure before secure messages can be exchanged (used to verify each party). That eats up CPU cycles, putting a drag on network performance. Similarly, the mathematical computations used when public and private keys are combined can slow down each platform’s CPU. All in all, net managers can expect to take a 20 percent hit on network performance when using public key products.

No matter which scheme is implemented, key management remains an issue to be reckoned with--particularly as networks grow larger and more users are added to the mix. Vendors are looking to address this shortcoming with automated key exchange mechanisms that reduce the delays and Management problems associated with private keys.

Figure 1
With private-key cryptography, each end-user is assigned a unique key that encrypts and decrypts data (a). When end-users want to communicate, they must first swap keys, which can lead to security breaches. What's more, private keys are typically distributed by mail or phone--another possible security breach. Public-key cryptography, in contrast, relies on two keys (b). Private keys must still be distributed, but public keys are published on the network. The two are used together to encode and decode data; there's no need to exchange private keys.
 

What's being encrypted?
Some products encrypt the entire packet, including the header, actually encapsulating it in a second IP packet. That's the best bet, but it can cause problems on the network. Other security devices only encrypt the payload. If just the data is encrypted the source and IP address remain unchanged. Thus, a hacker with a network analyzer could pull a packet from the network and figure out where it's headed. This doesn't sound like a big deal, but a smart cyberspook can use this information to locate routers or other devices behind the firewall. This is the first step in mounting an IP spoofing attack, in which outside intruders attempt to fool the firewall into thinking they're on a company's internal network. This isn't possible if the entire packet is encrypted (encapsulated in a second IP packet). Products that do this implement IETF RFC (Requests for Comment) 1827, the IP Encapsulating Security Payload (ESP) spec. Simply said, RFC 1827 gives a security device like a firewall or router a standard way to append new source and destination addresses to an IP packet. These addresses are only for the firewalls at either end of the link. But there's a problem. Adding a new header can double the size of the IP packet size. If it gets big enough it can exceed the legal limit, causing packet fragmentation, which dumps the overflow from one packet into another. When the fragmented packets arrive at the destination, it takes more time to reassemble and decode them. And that process can stretch out even further since IP packets don't necessarily arrive in the sequence that they're sent. Besides spoofing attacks, IP encapsulation also protects against hijacking. In this scenario, hackers use network analyzers to peer into packets as they're passed between nodes. If they spot something interesting, they desynchronize the two nodes, fooling the machines into thinking they're still talking while they're not--without dropping the link. Once this is done, the hackers can grab the packets they want, insert their own code, and slip the "legitimate" packets into the data stream. When they reach their destination, the hacker code can execute on a server or end-station. Hijacking is a particular problem on Internet links, because 1 percent to 5 percent of the packets are ordinarily junked. Thus, end-stations are fairly tolerant of dropped packets. This makes it very tough for net managers to spot hackers who've desynchronized machines. But encryption alone isn't enough. Full-fledged protection also demands authentication.

What does the authentication means?
The property of knowing that the data received is the same as the data that was sent and that the claimed sender is in fact the actual sender. This can be achieved by variety of methods from security cards to certificate authorities.

After introducing the basic concepts about security let’s see how the IPSEC works.

What is IPSEC?
IPSEC is a collection of security protocols from the IETF (Internet Engineering Task Force) that adds authentication and encryption to all IP communications. IPSEC operates in the IP layer and secures anything using UDP or TCP. Like IP itself, IPSEC is versatile. Its authentication features let net managers’ guard against attacks launched from inside or outside the network. And encryption keeps hackers from decoding packets as they traverse the links—good news for companies that want to establish connections to trading partners, suppliers, or customers over the Internet. Better yet, IPSEC lets net managers choose just what kind of encryption they want to use.

Introducing IPSEC
One of the beauties of TCP/IP is its extensibility—whenever a new service is needed, it can be layered over the existing framework. A conventional packet contains an IP header, which consists of a source and destination address, control fields, and information about the packet contents (the payload). One of the control fields is a "next protocol" field: It specifies what immediately follows the header. In the case of IP packets, the next protocol probably will be TCP or UDP (universal datagram protocol), but not necessarily. Because all protocols in the TCP/IP suite have a "next protocol" field as part of the header format, they can be combined in different ways—and that's where IPSEC fits in. IPSEC adds new fields to packet headers, and these fields are what make authentication and encryption possible. Authentication assures the recipient that an IP packet has come from the actual sender. IPSEC protocols validate the packets with a secret key that the receiver and sender share. Since most network communications involve packets sent in both directions, this process authenticates both parties. But that's where it ends: Authentication simply confirms the source of the packet—it does nothing to hide its contents. That's where encryption comes in: IPSEC codes packets flowing between sender and receiver, which guard against so-called man-in-the-middle attacks. So even if a hacker intercepts packets, the contents are meaningless. But by themselves, neither authentication nor encryption assures a secure connection. It's the combination that counts: When used together, they can protect such sensitive information as financial data, passwords, corporate information, and e-mail.
The term IPSEC actually covers a series of protocols used to send authenticated and/or encrypted data over IP networks. Roughly speaking, the protocols fall into three categories:

1. Authentication header (AH), which provide source authentication and integrity for the IP diagram.
2. Encapsulating security payload (ESP) use to provide cofidetiality.
3. IP Security association key management protocol (ISAKMP), which manages the exchange of secret keys between senders  and recipients of ESP or AH packets.

What is ESP?
ESP defines the possible content (payload) for an IP packet. An ESP packet consists of a control header, a data payload, and an optional authentication trailer (see Figure 2). The control header contains a security protocol identifier (SPI) and a sequence number field. It may also contain control information needed by some cryptographic algorithms like Data Encryption Standard (DES); this optional field is called the initialization vector (IV). The data payload is an encrypted version of the user's original packet, and the authentication trailer contains a digital hash (the output of a checksum-like algorithm) to validate the authenticity of the packet. The ESP protocol is required to prevent an attacker from reading your sensitive information as it moves across the open network. If we look closer in a packet with ESP (see Figure 3) we can find IP header followed by SPI, followed by opaque data (typically an initialization vector IV ciphertext). The sender appends padding, pad length, and payload type to the plain text payload data. The padding is necessary to make the size of the data multiple of the width of the cryptographic mechanism. Most cryptographic algorithms operate on 64-bit blocks of data. The sender generates an initialization vector that both the sender and the receiver use to set the initial state of the cryptographic mechanism. The sender then uses the secret key shared by the sender and the receiver to encrypt the payload data, padding, pad length, and payload type. The resulting ciphertext is placed in the IP diagram and send to the receiver. The receiver uses the SPI to determine which secret cryptographic key to use to decrypt the data.

How does ESP encrypt the payload?
It encrypts by using one of the several cryptographic algorithms—typically DES. DES is available in both software and hardware, and there are no patent issues to worry about. Another commonly used algorithm is Triple DES, which uses three DES operations to boost cryptographic strength. But there's something to keep in mind about both DES and Triple DES (and many other cipher algorithms): the U.S. government tightly controls their export.

Figure 2
To authenticate packets, IPSEC inserts the ESP header after the IP header (a). To encrypt packets in ESP tunnel mode, IPSEC wraps the entire packet in new, larger packet (b).
 

Figure 3
Detailed form of an IP packet with ESP.
 

What is AH?
Like ESP, the AH packet format also defines packet payload—but for authentication purposes only. The AH header contains security parameter index SPI, a sequence number, and an authentication value (see Figure 4). The Authentication Header immediately follows the IP header (see Figure 5). AH contains the next header, length, reserved field, SPI, and authentication data. SPI is a security parameter index, which consists of cryptographic keys, algorithms, and related information.
The authentication data is a value computed as function of the IP diagram and the secret authentication keying material, which is part of the security association. Only the sender and the receiver know the secret keying material, so if the authentication data is valid, the receiver knows the data came from the other party in the security association. The receiver uses the SPI contained in the packet to determine which keying material to use when validating the authentication data. Authenticating the source of IP diagrams is necessary to protect against attacks such as IP spoofing and hijacking. However this is only half of the solution.

How does AH defines the payload?
To authenticate users, AH uses either the Message Digest 5 (MD5) algorithm, developed by RSA Data Security Inc. (Redwood City, Calif.), or Secure Hash Algorithm 1 (SHA-1), developed by the U.S. government are two algorithms commonly used with IPSEC. MD5 is faster then SHA-1 but SHA is regarded as more secure. But these aren't the only authentication algorithms. Others are now working their way through the IETF, including truncated HMAC (Hashed Message Authentication Code). Here, the digest operation is performed twice, and only a portion of the digest results is transmitted—which means an attacker will have a harder time faking an authentication value.

Figure 4
A conventional IP packet consists of a header and payload, usually combination of a TCP or UDP header and user data (a). The IP packet with AH consists of IP header followed by Auth. Header and the payload (b).
 

Figure 5
Detailed form of an IP packet with AH.
 

Both ESP and AH use cryptography. But AH only furnishes authentication through the digital hash; it does not encrypt data, so passwords and other sensitive information would still be visible to intruders. When used with a secret key, the message digest uniquely identifies each IP packet. A secret key is usually a value of 56 bits or longer, both the sender and the receiver knows this key. Encryption makes use of a digital cipher, an algorithm that employs a secret key to encode the message (the user's original IP packet). When both encryption and authentication are used, there are two keys. Both the sender and the recipient must know the value of those keys, and the value has to remain a secret. That's where ISAKMP comes in.

Notably, both ESP and AH can encrypt the sender's entire packet in a new, larger packet. But if that new packet is too large for a specific medium—say, larger than 1,518 bytes for Ethernet—one of two things happens. The packet is fragmented into two smaller packets, or it uses IP's path MTU (maximum transmission unit) discovery routines to inform the sender that the packet couldn't be processed.

Design Differences
Depending on where IPSEC runs, packets may or may not be encapsulated. When an end-system ("host" in IETF parlance) runs ESP or AH, the payload field is the data that normally follows the IP header (for example, a TCP or UDP header followed by user data). This is called transport mode, since the payload is simply transported from one point to another without modification. But when IPSEC is run in an internetworking device like a router, firewall, or VPN gateway, the payload is the end-user's entire packet—IP headers and all—placed within another packet with ESP or AH fields. This is called tunnel mode: The entire original packet travels through a "tunnel" from one point of a TCP/IP network to another. Since the original packet is encapsulated, the new, larger packet may have totally different source and destination addresses—and that in it self ensures greater security. Regardless of mode, the outermost packet header is still IP. That allows the packet to be transmitted through conventional routers, including those on the Internet.

What is ISAKMP?
ISAKMP is a protocol that automates key exchange, ensuring that they're delivered safely from one side to the other. ISAKMP is based on the Diffie-Hellman key exchange protocol, and it assumes the identities of the two parties are known.
This is done through passwords called pre-shared secrets, or through the use of digital certificates. Once each party's identity is known, ISAKMP exchanges information through a series of UDP messages to establish shared keys. When hosts or gateways use ESP or AH, they share configuration information by exchanging common SPIs. This information includes encryption algorithm, authentication algorithm, and keys used. With an automated mechanism like ISAKMP, it's possible to control the level of trust in the keys. This is similar to controlling the use of passwords, where net managers might require a change in passwords daily, weekly, or monthly. Further, ISAKMP lets net managers stipulate that SPIs be refreshed at an appropriate frequency. Because it uses digital digests and random-number generators, ISAKMP can guard against password-guessing attacks. As noted, key holders also can be identified via digital certificates. Use and management of certificates requires a certificate authority (CA)—either through third-party CA services, CA products, or custom-developed CA software.

Processing
Assume a sender has already performed ESP and AH processing to create an IPSEC packet. The steps required by a host receiving an IPSEC packet are: 

1. Examine the protocol header on the packet. When the AH header is found, to call AH processing.
2. Extract the SPI from the AH header. The SPI is used to extract shared secret (keys for AH) from the security association database.
3. Using the shared secret, calculate the authentication data. Only an entity with the shared secret is capable of calculating the correct authentication data.
4. Test the received authentication data against that just calculated. If the values match, the integrity of the data has not been compromised.
5. Discard the AH header and extract the ESP header. The ESP header contains it own SPI, which may be different from the AH SPI.
6. Extract the ESP SPI from the ESP header. This SPI is used to access the security association database a second time to retrieve the ESP receive key. (Smart implementation will cache the entire security association record when it is retrieved for AH processing.)
7. Decrypt the payload. The ESP key is loaded into the cryptographic algorithm. The initialization vector is extracted from the header and used to initialize the state of the receiver’s cryptography. The payload is then decrypted to recover the payload data and trailer information.
8. Remove the trailer and pass the payload on. The padding and the pad length are stripped off. The payload can then be passed up to the stack to the next protocol (UDP or TCP).

Table 1
Speed of the DES cryptographic algorithm.
 

The set-up time for the MD5 and SHA-1 is also significant. Performance measurements on a Sparc 20/71 demonstrates an MD5 throughput when using 1-KB packets drops to only about 1 percent of this. Buffer management can influence performance, although it is not as important as cryptographic processing. When designing parsing routines, we have to keep track of variables-length fields and their location in the packet. And we have to keep in mind that the authentication data used in the AH header is a function of the data that follows it. A common problem occurs when implementing cryptographic code is generating high-quality random numbers. A surprising number of systems have been successfully attacked because randomization was not performed properly.

In which cases and what kind of security association to use?
It depends on the situation: If authentication is all that's needed, AH is fine. AH by itself doesn't offer encryption, so it's not considered safe (passwords and other sensitive data would still be visible through a network tap). Similarly, ESP isn't fully secure unless its authentication feature is used. But if both authentication and encryption are required, then ESP with the authentication option is the right choice. A typical IPSEC configuration would use ESP with the authentication option, rather than ESP plus AH. That's because the combined ESP protocol is considered a better performer: There is only one "transform" operation, and the authentication data is placed at the end—which reduces the amount of copying done during packet processing. How to apply IPSEC and how much safety it provides?

Essentially, IPSEC handles two kinds of problems. First, consider those cases where a network contains information that should remain confidential—human resources data, medical information, and payroll records, for instance. Second, there are times when access to the network should be limited to authorized users entering through authorized equipment (this is increasingly important as companies build extranets linking them with trading partners). IPSEC addresses the first scenario with encryption and the second with authentication. But net managers also should keep in mind those situations where IPSEC is not the answer. IPSEC doesn't add anything when specific applications already use security facilities at other layers; it won't, for instance, help protect Web sessions guarded by the application-layer secure sockets layer (SSL) protocol. Similarly, it doesn't do anything for e-mail that's already protected by Pretty Good Privacy (PGP), nor will it protect credit-card processing transactions that use Secure Electronic Transmission (SET). In all of these examples, the application itself adds the security. IPSEC works the opposite way: The underlying network provides security, regardless of the applications involved. This leads to a common question in corporate environments: Who's responsible for furnishing security? It should be explicitly defined in a security policy. In many cases it's up to network managers, but sometimes security is just left to the network operations staff by default. In either case, the key issues remain. What should be guarded against, and how?

Securing the 'Net
IPSEC offers answers to both questions. It can be deployed two different ways: between gateways or between hosts. In the gateway-to-gateway scenario, trading partners might connect across the Internet (see Figure 6). This configuration also works within a company for two workgroups connected in a LAN-to-LAN configuration; here again, there would be a gateway at the edge of each network. IPSEC gateways will likely use tunnel-mode ESP. In this scenario, the packets are transmitted as "clear text" (unencrypted) from hosts to a gateway running IPSEC. The gateway encapsulates the IP packets in either encrypted or authenticated form and forwards them to a destination gateway, where they are authenticated, decrypted, and de-encapsulated. A VPN serves as a good example: Gateways at each end may service one LAN each or a more complex mix of hosts and LANs.
In the host-to-host configuration, just about every type of machine can communicate with another. This technology—which works at the network layer—lends itself to situations with a mix of machine types running TCP/IP. Consider, for example, a mainframe computer serving a mix of clients, some running 3270 terminal emulation programs and some running Java applets in Web browsers. All the machines can implement IPSEC through an upgrade to their TCP/IP software. (And even if hosts can't be upgraded, gateways still can secure the network.) IPSEC hosts will probably use transport-mode ESP to exchange encrypted IP packets. ESP encrypts the clear text data in the source packets, then sends the packets through the IP network and decrypts them at the destination host.

Figure 6
Secure communication-using IPSEC.
 

Net managers also need to determine how much cryptographic strength to use. One of the benefits of ISAKMP is that it doesn't mandate the use of any one cipher. Thus, net managers can choose different protocols based on their requirements. For instance, if a corporate vice president is dialing in from a hotel in Eastern Europe, the security of the link may be questionable, and a strong protocol like Triple DES, rekeyed every five minutes, might be used. On the other hand, DES might be sufficient for protecting a leased line between headquarters and a suburban warehouse. Aside from the technical decisions concerning tunnels and transports, net managers also need to decide who gets access to network resources. Perhaps some hosts on a LAN will not be granted access to some remote server—in which case the IPSEC gateway would have a policy database specifying those hosts that will be granted, access. Controlling who gets access can be done through configuration of the policy database using vendor-supplied tools, or through the use of digital certificates. Of course, for all these products performance is a key issue. Encryption, for instance, requires extra processing—so applying it to every packet could exact a performance penalty (here, hardware-based encryption might be helpful). ESP's extra overhead also will degrade network performance to some extent, since the protocol reduces the maximum amount of actual user data per individual packet. Then again, external factors could offset these performance drops. Take link speed: In a pure 100-Mbit/s LAN environment, the performance degradation of IPSEC will be noticeable. But two sites linked over a 256-kbit/s-frame relay circuit won't see any slowdown. Data compression also could reduce the effects of IPSEC on performance: Compressing data packets just before encryption, for instance, saves time, since there's less data to be encrypted.

Problems occurring while testing IPSEC
One of the main problems is occurring, while trying to set a Security Association (SA) between two different Operating Systems, which are implementing IPSEC, due to absence of common standard. It is almost impossible to create such SA. The other point of concern is the shortage of documentation and technical data provided by the vendors. Hopefully all of those problems will be solved in the further stages of development.

Potential Attacks
When developing security software, what the designer doesn’t know are all the possible security gaps in his software. There is a very simple example where the security gap can occur if the designer is not careful enough.

Let assume the configuration in Figure 7. “Your Host” has IPSEC security associations with two other hosts (“Good and “Evil”), each connection via router implementing IPSEC. Since all traffic coming into Your Host is protected by IPSEC, you might assume that Your Host could do access control based on the source address on the packet. This may not be the case. Let’s assume that Evil Host wants to send a packet to Your Host claming to be from the Good. Evil could construct packet that, when passed through its IPSEC router operating in tunnel mode, would have the format:

Outer IP address = Evil
Authentication Header IP address = Evil
IP address on tunneled packet = Good

When this packet arrives at your IPSEC router, it is processed like this:

1. The outer IP address is an address that your router recognizes. The packet is sent to IPSEC code for processing.
2. Evil has a valid security association (SA2) with your router. Your router extracts the SPI from the authentication header and validates the integrity of the packet. The integrity check confirms that the packet has not been corrupted (since the remote router sent it).
3. Your router extracts the SPI from ESP and decrypts the payload. This payload is a packet that was encrypted using tunnel mode.

Figure 7
Example network showing the potential for spoofing source addresses.
 

The future of IPSEC
The IETF is continuing its IPSEC effort, developing new security transforms that will provide even greater security. The protocol is also being enchanted to better utilize bandwidth. And IPSEC is a part of emerging IPv6 protocol.

GOING TO THE TOP

GOING TO THE MAIN PAGE