Both IPSec and SSL use PFS Perfect Forward Secrecy in their resumption session.

In the case of IPSec the main goal for Phase 1 beside authentication is producing the encryption key
required to safe guard Phase 2's exchange. Compromising Phase 1's key will result in decrypting Phase
2's. This will allow an attacker to produce the key and de crypt the data exchanged between the two
sides. PFS prevents such attack by exchanging new DH values each time a session is resumed.In the case
of SSL, PFS is implemented in the same manner as with IPSec when Ephemeral Diffe-Hellman is
negotiated.

IPSec encrypts the data first then creates MAC for the encrypted data. If a modified data were inserted
in the middle of transaction, IPSec would verify the MAC before performing any decryption process .

SSL is the opposite it creates the MAC for the plain text rst then encrypts the data . SSL on the other
hand is obligated to decrypt it firrst then verifies the MAC which could result in wasting CPU over
decrypting modified packets .

4.9

Because IPSec is a two phase protocol , it has a unique function called bi-directional. That is when
IPSec Phase 1 is established, both Initiator and Responder can initiate Phase 2 negotiation. SSL is a one
direction protocol .

4.10

IPSec doesn’t integrate well with other IPSec vendors. Some cases require some modification.SSL is
trouble free and well integrated.

4.11

One disadvantage of IPSec is the extra size added to the original packet. SSL needs less overhead than
IPSec. The extra required bytes for each protocol are described in table 8.

IPSec Tunnel Mode requires adding another 20 Byte IP header. All the data above don’ t include the
padding bytes and the pad length.

4.12

IPSec resides in the IP layer which allows it to work with the above layers smoothly, SSL resides in the
Application layer and that is a problem for some application to work with SSL . As we mentioned,
Stunnel is a solution for the TCP based applications to work with SSL . Since IPSec is an IP layer protocol.
It could be placed inside the kernel or as a separate machine out side the PC . Placing IPSec outside the
machine called bump-in-the-wire BITW . Placing IPSec inside the machine between two layers is called
bump-in-the-stack (BITS).

Because IPSec resides in the IP layer , it allows multi- users to use one tunnel between two endpoints
while SSL allow multi-users to have individual connections and different encryption key for each
connection. The merit of using one tunnel for multi users as with IPSec is to lower the overhead caused
by establishing individual connections. The merit of using independent connection ,as with SSL, is that
each user has individual session . Consequently, compromising one connection doesn’t compromise the
other connections .

4.13

The time to establish a session is another element. Table 9 shows how much time is needed to establish
a session for IPSec . The results are based on the use of a 2048 bit RSA key and 1536 bit DH.

Table 10 shows the time required for establishing SSL session . The results are based on the use of a
2048 bit RSA key and 768 bit DH . Using 1536 bit in DH has consumed 1648 msec in the Client
Authentication. That is considered extremely slow when it is compared with 768 bit.

4.14

The concept behind resuming a session is reducing the handshake process while maintaining a full
security level. As mentioned in the Residing Layer Section the fact that each protocol works in a different
layer has influenced the concept of session resumption . With SSL, the secure channel is bound to the
application that required the secure service. Once the application is finished the secure channel shuts
down.

When SSL session is resumed within the expiration, the client and the server exchanges the session ID
(32 Byte) from the previous session in the clear and with it both side can identify the pre master key
and produce the new session key needed to secure the information. Table 11 shows the time needed to
resume a session in SSL.

IPSec’s session resumption concept is totally different from SSL and is called Rekeying. Since IPSec is not
bound to any application and has two different Phases, Rekeying mechanism is a bit complicated.

SA life time is responsible for how and when rekeying should occur.ISAKMP SA and IPSec SA are not
obligated to have the same life time. Therefore, IPSec SA can be shorter in time than ISAKMP SA. What
happens when ISAKMP SA expires before IPSec SA? This issue has not been standardized yet but IKEv2
draft has proposed a standard for it. At the moment two different concepts are implemented:
Continuous channel and Dangling SA.

Continuous channel

If ISAKMP SA expires then IPSec SA must be deleted. The reason is that ISAKMP SA is responsible for
exchanging informational messages such as delete notification and Dead Peer Detection.
Dangling SA

Even with the expiration of ISAKMP SA, IPSec SA is valid until it reaches the validity time since ISAKMP
SA has completed it mission of authentification and governed the negotiated secure channel.

Then, when IPSec SA rekeying is required, the rekeying process will depend on the ISAKMP SA status;
If ISKAMP SA expired before IPSec SA

In Continuous channel, IPSec is deleted and a new Phase1 and Phase2 are negotiated .

In Dangling SA, when IPSec SA asks for rekeying, then Phase1 and Phase2 are negotiated .

If IPSec SA expired before ISAKMP SA and asked for rekeying in Continuous-channel or Dangling SA.
Then, only Phase 2 is negotiated.

Table 12 shows the time needed to rekey an IPSec session within the expiration of ISAKMP SA.

4.15

As mentioned in 4.6, SSL clients are not bound to a specific port, therefore the exisitence of NAT in the
middle of the network doesn’t affect the communications. IPSec clients on the other hand are bound to
specific ports, thus having NAT or NAPT in the middle causes a problem for IPSec. Fortunately a solution
has been proposed and been used by many vendors.

4.16

Compression is utilized by IPSec through a com pression protocol called IPComp. IPSec supports
DEFLATE,LZS and LZJH. Unfortunately compression is used in a small range with SSL. Only OpenSS
supports compression.

We have experimented the compression algorithm in two different environments and we had two
opposite results . The first experiment was conducted on a 100 Mbps NIC and Mbps Switching Hub.
Compression Algorithm increased the throughput see table 14 and 16).

The second experiment was conducted on a 1000 Mbps NIC and a 1000 Mbps Switching Hub. The
Compression Algorithm decreased the throughput when used with most of the encryption algorithm
except with 3DES where the throughput increased (see table 13 and 15).

The reason the first case has shown some improvement in throughput was the relevant speed between
the compression, the encryption and the transfer. The network topology has caused a bottle neck. The
through put increased because the compression speed was faster than the transfer speed.
In the second case, the reason was the relation between the encryption speed and the compression.
Most of the encryption algorithms are faster than the com pression except for 3DES. Therefore, applying
the compression to a higher speed encryption algorithm will cause the throughput to fall down

4.17

The experiments were conducted on two machines with the following :

4.17.1

Table 13 shows the throughput on a 1000 Mbps network. CPU consumption varied between and 94% and
97%.

3DES is the most consuming algorithm. When com pression was applied the consumption was 98% regard
less of algorithm or network status.

Table 14 shows the throughput on a 100 Mbps network. The use of compression algorithm on a low band
width network has shown tremendous change in speed. CPU consumption was 76% for DES , 90% for 3DES and
57% for AES.

4.17.2

Table 15 shows the throughput on a 1000 Mbps network. CPU consumption varied between 87.7% and
93%.

Table 16 shows the throughput on a 100 Mbps network. Compression algorithm has shown change in speed.
CPU consumption was 57% for DES, 87% for3 DES and 44.3% for AES.

4.17.3
 Table 17 shows the result conducted on a 1000 Mbps network CPU consumption varied between 86% and
93%.

Table 18 shows the result conducted on a 1000 Mbps network. CPU consumption was 91.2% for 3DES,
58% for DES, 36.5% for RC-SHA, 27.8% for RC-MD5 and 87% for RC2

Conclusions

We presented the resemblance and the differences between IPSec and SSL. Each of the protocols has
unique properties. Choosing IPSec or SSL depends on the security needs. If a specific service is required and is
supported by SSL, it is better to select SSL. If over all services or Gateway-to-Gateway communications are
needed then IPSec is a good choice considering the following. IPSec uses a shorter form of HMAC than SSL, thus
SSL data integrity is more secure. SSL is more compatible with rewall than IPSec, unless IPSec and Firewall are
integrated in the same device. Unlike SSL IPSec clients need a special IPSec software for remote access. In low
bandwidth networks or dial up networks using compression is beneficial, SSL doesn’t support that. Pre-Shared
scheme is easier to configure and doesn’t require any PKI infrastructure, IPSec supports compression but
unfortunately SSL doesn’t support it IPSec is capable of protecting wireless networks. In most cases IPSec
doesn’t interoperate well, so both sides of the connection are required to have the same vendor s devices see table