A Technical Comparison of IPSec and SSL

y

Ab delNasir Alshamsi Takamichi Saito

Tokyo University of Technology

Abstract p osed but the most famous secure and widely de

ployed are IPSec IP Security and SSL Secure

So cket Layer

IPSec IP Security and SSL SecureSocket Layer

In this pap er we will provide a technical comparison

have been the most robust and most potential tools

of IPSec and SSL the similarities and the dierences

available for securing communications over the Inter

of the cryptographic prop erties The results of per

net Both IPSec and SSL have advantages and short

formance are based on comparing FreeSWAN as

comings Yet no paper has been found comparing the

IPSec and Stunnel as SSL

two protocols in terms of characteristic and functional

ity Our objective is to present an analysis of security

and performancepr operties for IPSec and SSL

IPSec

IPSec is an IP layer proto col that enables the

Intro duction

sending and receiving of cryptographically protected

packets of any kind TCPUDPICMPetc without any

provides two kinds of crypto mo dication IPSec

Securing data over the network is hard and compli

graphic services Based on necessity IPSec can provide

cated issue while the threat of data mo dication and

condentiality and authenticity or it can provide

data interruption is rising The goal of network security

authenticity only

is to provide condentiality integrity and authenticity

Condentiality is keeping the data secret from the

ESP Encapsulated SecurityPayload

unintended listeners on the network Integrity is en

suring that the received data is the data was actually

AH Authentication Header

sent Authenticity is proving the identity of the end

ESP provides condentiality authenticity and in

point to ensure that the end p ointistheintended entity

tegrity protection for the communication and it is dis

to communicate with

tinguished by the ESP header attached to the packet

The combination of these prop erties is the pillar of

AH on the other hand ensures that authenticity and

the security proto cols How to combine them is the

integrity of the data is protected and it is identied

ers Using a strong crypto question with many answ

by the AH header attached to the packet ESP header

graphic key with a weak authentication algorithm may

includes the necessary information for decrypting and

allow an attacker to disrupt the data Using a strong

authenticating the data where AH header includes the

authentication algorithm with a weak encryption algo

necessary information required for authenticating the

rithm may allowanattacker to decrypt the data Using

protected data

both strong authentication and encryption algorithm

Establishing IPSec connection requires two phases

protects the data but it will decrease the transmission

Phase ISAKMP SA and Phase IPSec SA

rate and could induce CPU consumption Therefore

see table

it is complicated to provide the b est protection the

maximum throughput and the lowest overhead

Phase

With the recent development of the securitytools

so many proto cols and powerful to ols have been pro

Phase p erforms mutual authentication and pro

Graduate Scho ol of System Electronics Katakurcho

duces the encryption key required to protect Phase

Hachiouji City Japan alshamsiaquatsitteuacjp

y

Phase has two mo des Main Mo de and Aggressive

Department of Computer Science Katakurcho Ha

Mo de The dierences between these two mo des are chiouji City Japan saitoccteuacjp

the numb er of messages exchanged and the ID protec SA Security Asso ciation

tion see table

KE DieHellman exchanged public value

Main Mo de

Ni Nr the nonce

I ID R the Initiator Resp onder ID

CERT the certicate

SIG I SIG R the signature for the Initiator Re

sp onder resp ectively

x x is optional

Figure IPSec Main Mo de

encryption must b egin after the header

Key Exchange and Authentication

AggressiveMode

Various metho ds of Key Exchange mechanism and

Authentication metho ds are supp orted by IPSec

Key Exchange Metho d

DH

KINK

Authentication Metho d

Figure IPSec AggressiveMode

PreShared Key PSK

Phase

Digital Signature

Phase negotiates the cipher and authentication

Public Key

algorithm required to protect further transactions

Phase has one mo de QuickMode

KINK see

The Hash Algorithms used by IPSec are MD and

SHA see

Table IPSec Mo de

Phase Key Exchange Mo de Msg Exchanged

Phase Main Mo de

Figure IPSec QuickMode

AggressiveMode

Phase QuickMode

The notations below were used to describ e Figure

and

IPSec Notation

KINK is a Kerb eros based proto col that provides Key Ex

change and authentication mechanism Not standardized yet

HDR ISAKMP header such as RSA Digital Signature and DSA Digital Signature

Server Authentication

Table ID Protection

ClientAuthentication

Mo de Authentication Metho d ID Protection

PSK yes

Anonymous see

Main RSADSA Digital Sig yes

Client Authentication is in fact mutual authentica

Public Key yes

tion but the develop ers of SSL has referred to it as

PSK no

Client Authentication The Hash Algorithms used

Aggressive RSADSA Digital Sig no

by SSL are MD and SHA see

Public Key yes

An example of a SSL Handshake is describ ed in Fig

ure

SSL

SSL Secure So cket Layer is an Application layer

proto col SSL is mostly utilized to protect HTTP

transactions and has b een used for other purp oses like

IMAP and POP etc SSL is compatible with applica

tions running only over TCPbut some mo dications

are required for the applications to run over SSL Re

centdevelopment of SSL software like Stunnel has

added an easiness of use to SSL SSL is comp osed of

the following proto cols

Handshake proto col

Change Cipher Sp ec proto col

Alert proto col

Application Data proto col

Figure SSL Handshake

Handshake proto col is used to p erform authentica

tion and key exchanges Change Cipher Sp ec proto col

Figure describ es SSL handshake in Client Authen

is used to indicate that the chosen keys will now be

tication The remove of the attached exchanges rep

used Alert proto col is used for signaling errors and

resents Server Authentication

session closure Application Data proto col transmits

and receives encrypted data

SSL Notation

ClientHello Client prop oses supp orted cipher suite

Authentication Key Exchange and

ServerHello Server sends chosen cipher suite

Key Exchange Metho d

Certicate Server sends certicate

RSA

CerticateRequest Server requests Clients Certi

Client sends the pre master secret after encrypt

cate

ing it with Servers public key

ServerHelloDone Server has sent all Handshake

DH

messages

ClientandServer exchange DH public values and

pro duce the pre master secret indep endently

Certicate Client sends Certicate



Other Key Exchange metho ds are used with SSL but

ClientKeyExchange Client sends pre master secret

in this pap er we will only refer to the ab ove mentioned

encrypted with Servers public key

metho ds

Authentication Metho d

ChangeCipherSp ec Client sends New chosen ci



Kerb eros FORTEZZA pher suite will b e selected

Finished nished message

Table HMAC Algorithm Typ e

ChangeCipherSp ec Server sends New chosen ci

Proto col MAC Algorithm Hash Length

pher suite will b e selected

IPSec HMACSHA Byte

HMACMD Byte

Finished nished message

SSL HMACSHA Byte

HMACMD Byte

Comparison of IPSec and SSL

Authentication Algorithm

to pro duce message digest The strength of the Hash

IPSec supp orts the use of Digital Signature and the

Algorithm is based on the length of the output see ta

use of a Secret Key Algorithm where SSL supp orts

ble

only the use of Digital Signature The use of a random

bit Secret Key is considered as strong as any other

authentication metho ds In the absence of Digital Sig

Connection Mo de

nature algorithm IPSec can still b e implemented using

the Secret Key but SSL cant b e implemented

IPSec has two connection mo des

Tunnel Mo de

Authentication Metho d

This is established b etween GatewaytoGateway

GatewaytoHost and HosttoHost It establishes

IPSec supp orts one typ e of authentication metho d

a tunnel between the endp oint and it requires

while SSL supp orts a various typ es of authentication

adding a new IP header to the original packet

They are describ ed in table and

Transp ort Mo de

Table IPSec Authentication Metho d

Transp ort Mo de is HosttoHost connection The

data b etween the twoentities are encrypted

Authentication Metho d Authentication Algorithm

The advantage of Tunnel Mo de is the elimination of

Mutual Authentication PSK

the overhead caused by eachchannel But the disad

RSADSA Digital Signature

vantage is what could happ en to the connection if the

RSA Public Key

key was compromised

KINK

SSL is a vice versa situation SSL is one connec

tion p er one session typ e Each session is indep endent

but the throughput could fall down as the number of

sessions increases

Table SSL Authentication Metho d

Remote Access

Authentication Metho d Authentication Algorithm

Server Authentication RSA ChallengeResp onse

IPSec encoun ters some problems when it comes to

DSA Digital Signature

remote access with PSK authentication in Main Mo de

Client Authentication RSADSA Digital Signature

In the case of PSK the ID is restricted to the IP ad

Anonymous none

dress only Since the IP address is not static the prop er

shared key cant be lo cated and as a result Remote

Host cant b e established Toavoid such incidentthe

following metho ds are prop osed

MAC

Setting the remote host IP to and using one

MAC Message Authentication Co de is used for au

Shared Key for remote host access

thenticating the exchanged messages after the connec

Using Aggressive Mo de where the ID typ e is not tion is established Both IPSec and SSL require the

restricted to the IP address and it is sent to the implementation of HMACSHA and HMACMD

resp onder at the b eginning of the negotiation HMAC is a hash function that requires a secret key



Adapting User Authentication scheme like PIC

Table IPSec SSL and Ports



orXAUTH

Proto col Mo de Ports

Using one key can compromise the security of the

IPSec Server ESP TCP

network if it is lost or stolen Besides changing the

AH TCP

key from time to time must require all clients to ad

Client ESP TCP

just their setting Aggressive Mo de sends the ClientID

AH TCP

in the clear and with that some risk exists User Au

SSL Server HTTPS TCP etc

thentication can add overhead to the pro cess but the

Client any

results are satisfying XAUTH is prop osed as a User

Authentication proto col for IPSec where the user au

thentication is conducted after the completion of Phase

and b efore starting Phase If the user is authenti

the p orts arent op en until SSL successfully negotiated

cated then the service is granted see table Remote

at the rewall and then forwarded to the SSL requiring

access with Digital Signature do esnt require anymod

application

ication

Perfect Forward Secrecy

Table Remote Access Prop osal for PSK

Both IPSec and SSL use PFS Perfect Forward Se

Solution Risk Overhead

crecy in their resumption session

One PSK key high low

In the case of IPSec the main goal for Phase b e

AggressiveMode medium low

side authentication is pro ducing the encryption key re

User Authentication low high

quired to safe guard Phase s exchange Compromis

ing Phase s key will result in decrypting Phase

This will allow an attacker to pro duce the key and de

crypt the data exchanged b etween the two sides PFS

SSL authentication over TCP is based on the ex

prevents such attack by exchanging new DH values

change of RSA ChallengeResp onse or DSA Digital

each time a session is resumed Signature during Server Authentication and RSADSA

In the case of SSL PFS is implemented in the same

Digital Signature during Client Authentication and

manner as with IPSec when Ephemeral DieHellman therefore remote access is p erformed without any needs

is negotiated for mo dication

Order of Cryptographic Op erations

Around Transp ort Layer

IPSec encrypts the data rst then creates MAC for

IPSec Phase negotiations are exchanged over the

the encrypted data If a mo died data were inserted in

UDP p ort only Thus Retransmit Timer must

the middle of transaction IPSec would verify the MAC

b e prepared to maintain SSL Handshake is exchanged

b efore p erforming any decryption pro cess

over TCP and unlike IPSec the p ort can b e changed

according to the application

As a Server b oth IPSec and SSL are b ound to sp e

cic p orts where as a Client IPSec is b ound to sp ecic

p orts but SSL is not see table

SSL works only over the TCP since UDP can cause

data to b e arbitrarily lost or reordered IPSec avoids

the UDP problem by adding a new TCP header to the

Figure IPSec

original packets eld whichallow UDP or TCP based

applications to work with IPSec Supp orting only TCP

application is a shortcoming of SSL

When IPSec is b ehind arewall all p orts of IPSec

SSL is the opp osite it creates the MAC for the plain

must b e in a p ermanent listening status at the rewall

text rst then encrypts the data SSL on the other

SSL situation is dierent when it is b ehind a rew all

hand is obligated to decrypt it rst then veries the



MAC which could result in wasting CPU over decrypt

PreIKE Credential Provisioning Proto col



ing mo died packets Extended Authentication

with SSL Since IPSec is an IP layer proto col It could

be placed inside the kernel or as a separate machine

out side the PC Placing IPSec outside the machine

called bumpinthewire BITW Placing IPSec inside

the machine b etween twolayers is called bumpinthe

stackBITS

Figure SSL

ws multi Because IPSec resides in the IP layer it allo

users to use one tunnel between two endp oints while

SSL allow multiusers to have individual connections

and dierent encryption key for each connection The

merit of using one tunnel for multiusers as with IPSec

Cipher List Prop osal

is to lower the overhead caused by establishing individ

ual connections The merit of using indep endentcon

Because IPSec is a two phase proto col it has a

nection as with SSL is that each user has individual

unique function called bidirectional That is when

session Consequently compromising one connection

IPSec Phase is established b oth Initiator and Re

do esnt compromise the other connections

sp onder can initiate Phase negotiation SSL is a one

direction proto col

Time of Handshake Pro cess

Interop erability

The time to establish a session is another element

Table shows howmuch time is needed to establish a

IPSec do esnt integrate well with other IPSec ven

session for IPSec The results are based on the use of

dors Some cases require some mo dication SSL

a bit RSA key and bit DH

is trouble free and well integrated

Overhead Size

Table IPSec HandshakeTime

Mo de Establishing

One disadvantage of IPSec is the extra size added

to the original packet SSL needs less overhead than Main Mo de PSK msec

IPSec The extra required bytes for each proto col are

Aggressive Mo de PSK msec

describ ed in table

Main Mo de RSA msec

Table Overhead Size

Table shows the time required for establishing

Proto col Mo de Byte Size SSL session The results are based on the use of a

bit RSA key and bit DH Using bit in DH

IPSec Tunnel Mo de ESP

has consumed msec in the ClientAuthentication

ESP and AH

That is considered extremely slow when it is compared

IPSec Transp ort Mo de ESP

with bit

ESP and AH

SSL HMACMD

HMACSHA

Table SSL HandshakeTime

Mo de Establishing

Server Authentication msec

IPSec Tunnel Mo de requires adding another Byte

Client Authentication msec

IP header see All the data ab ove dont include

Server Authentication DieHellman msec

the padding bytes and the pad length

Client Authentication DieHellman msec

Residing Layer

IPSec resides in the IP layer whichallows it to work

Session Resumption and Rekeying

with the ab ovelayers smo othly SSL resides in the Ap

plication layer and that is a problem for some appli

cation to work with SSL As we mentioned Stunnel The concept b ehind resuming a session is reducing

is a solution for the TCP based applications to work the handshake pro cess while maintaining a full security

level As mentioned in the Residing Layer Section the

fact that each proto col works in a dierent layer has

inuenced the concept of session resumption With

SSL the secure channel is b ound to the application

that required the secure service Once the application

is nished the secure channel shuts down

When SSL session is resumed within the expiration

Figure ISAKMP SA expires b efore IPSec SA

the clientandtheserver exchanges the session ID

Byte from the previous session in the clear and with it

b oth side can identify the premasterkey and pro duce

the new session key needed to secure the information

Table shows the time needed to resume a session in

In Continuouschannel IPSec is deleted and a new

SSL

Phase and Phase are negotiated

In Dangling SA when IPSec SA asks for rekeying

Table SSL Resumption

then Phase and Phase are negotiated

Mo de Time

If IPSec SA expired b efore ISAKMP SA Figure and

Server Authentication

asked for rekeying in Continuouschannel or Dangling

Client Authentication msec

SA Then only Phase is negotiated

Server Authentication DieHellman

Client Authentication DieHellman

IPSecs session resumption concept is totally dier

ent from SSL and is called Rekeying Since IPSec is not

b ound to any application and has two dierent Phases

Rekeying mechanism is a bit complicated

SA life time is resp onsible for how and when rekey

Figure IPSec SA expires b efore ISAKMP SA

ing should o ccur 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 happ ens when ISAKMP SA expires b efore IPSec

Table shows the time needed to rekey an IPSec

SA This issue has not been standardized yet but

session within the expiration of ISAKMP SA

IKEv draft has prop osed a standard for it At

the moment two dierent concepts are implemented

Continuouschannel and Dangling SA

Table IPSec Session Rekeying for Phase

Continuouschannel

Mo de Time

be If ISAKMP SA expires then IPSec SA must

Main Mo de PSK

deleted The reason is that ISAKMP SA is re

AggressiveModePSK msec

sp onsible for exchanging informational messages

Main Mo de RSA

such as delete notication and Dead Peer Detec

tion

Dangling SA

NAT Traversing

Even with the expiration of ISAKMP SA IPSec

SA is valid until it reaches the validity time since

As mentioned in SSL clients are not b ound to

ISAKMP SA has completed it mission of authenti

a sp ecic p ort therefore the exisitence of NATinthe

cation and governed the negotiated secure channel

middle of the network do esnt aect the communica

Then when IPSec SA rekeying is required the tions IPSec clients on the other hand are b ound to

rekeying pro cess will dep end on the ISAKMP SA sta sp ecic p orts thus having NAT or NAPT in the mid

tus If ISKAMP SA expired b efore IPSec SA Figure dle causes a problem for IPSec Fortunately a solution

has b een prop osed and b een used bymanyvendors

Compression Algorithm IPSec ESPSHA

Table shows the throughput on a Mbps net

Compression is utilized by IPSec through a com

work CPU consumption varied b etween and

pression proto col called IPComp IPSec supp orts

DES is the most consuming algorithm When com

DEFLATE LZS and LZJH Unfortunately compres

pression was applied the consumption was regard

sion is used in a small range with SSL Only OpenSSL

less of algorithm or network status

supp orts compression

We have exp erimented the compression algorithm

in two dierentenvironments and wehadtwo opp osite

Table Mbps Network IPSec

results The rst exp erimentwas conducted on a

Mbps NIC and Mbps Switching Hub Compression

Algorithm Throughput Mbps

Algorithm increased the throughput see table and

No Compression Compression

No Algorithm NA

The second exp eriment was conducted on a

DES

Mbps NIC and a Mbps Switching Hub The Com

DES

pression Algorithm decreased the throughput when

AES

used with most of the encryption algorithm except with

BLOWFISH

DES where the throughput increased see table and

The reason the rst case has shown some improve

Table shows the throughput on a Mbps net

ment in throughput was the relevant sp eed b etween the

work The use of compression algorithm on a lowband

compression the encryption and the transfer The net

width network has shown tremendous change in sp eed

work top ology has caused a b ottle neck The through

CPU consumption was for DES for DES

put increased b ecause the compression sp eed was faster

and for AES

than the transfer sp eed

In the second case the reason w as the relation b e

Table Mbps Network IPSec

tween the encryption sp eed and the compression Most

of the encryption algorithms are faster than the com

Algorithm Throughput Mbps

pression except for DES Therefore applying the com

No Compression Compression

pression to a higher sp eed encryption algorithm will

No Algorithm NA

cause the throughput to fall down

DES

DES

Performance

AES

The exp eriments were conducted on two machines

with the following

Red Hat kernel

IPSec ESPMD

Pentium GHz RAM MB

Table shows the throughput on a Mbps net

work CPU consumption varied between and

NIC Mbps and Mbps

Mbps and Mbps Switching Hub

Sup er FreeSWAN

Table Mbps Network IPSec

Stunnel

Algorithm Throughput Mbps



No Compression Compression

Ethereal

No Algorithm NA



Ip erf

DES

DES

The results have shown a variation of throughput

AES

sp eed and CPU consumption

BLOWFISH



network proto col analyzer and time measuring to ol



throughput measuring to ol

Table shows the throughput on a Mbps net

Table Mbps Network SSL

work Compression algorithm has shown change in

sp eed CPU consumption was for DES for

Algorithm Throughput

DES and for AES

No Algorithm Mbps

DESEDECBCSHA Mbps

Table Mbps Network IPSec

DESCBCSHA Mbps

RCSHA Mbps

Algorithm Throughput Mbps

RCMD Mbps

No Compression Compression

EXPRCCBCMD Mbps

No Algorithm NA

DES

DES

IPSec

AES

As with IPSec wehave tested the sp eed of various

algorithm but we will only include the results of

DES in various mo des see table

SSL

Table IPSec Transfer Sp eed

Our exp eriment includes the case of using exp ortable



keys like EXP and EXP RSA keys the

Algorithm Time Sec

throughput rate and CPU consumption dont showany

No Algorithm

change For this reason it will not b e included in this

DESSHA

pap er

DESMD

Table shows the result conducted on a Mbps

DESSHADEFLATE

network CPU consumption varied b etween and

DESMDDEFLATE

AESSHA

AESSHA

Table Mbps Network SSL

Algorithm Throughput

SSL

No Algorithm Mbps

SSL has shown various typ es of sp eed The b est

results could be achieved using RC with MD

DESEDECBCSHA Mbps

DES has shown a b etter p erformance than IPSec

DESCBCSHA Mbps

under the same circumstances see table

RCSHA Mbps

RCMD Mbps

EXPRCCBCMD Mbps

Table SSL Transfer Sp eed

Algorithm Time Sec

Table shows the result conducted on a Mbps

No Algorithm

network CPU consumption was for DES

DESEDECBCSHA

for DES for RCSHA for RCMD and

DESCBCSHA

for RC

RCSHA

RCMD

Transfer Sp eed of MB of Data

EXPRCCBCMD

Table and show the result of transferring a

MB of data over a Mbps network Transferring a

MB over a Mbps network has shown a slower

Conclusion

transfer rate except with DES DES didnt show a

visible change in rate



We presented the resemblance and the dierences

US law requires using limited RSA encryption key length for

exp ortable application The exp ort control was relaxed between IPSec and SSL Each of the proto cols has

unique prop erties Cho osing IPSec or SSL dep ends on D Maughan M Schertler M Schneider J

the security needs If a sp ecic service is required and is Turner Internet Security Association and Key

supp orted by SSL it is b etter to select SSL If over all Management Protocol ISAKMP RFC

services or GatewaytoGateway communications are Nov

needed then IPSec is a good choice considering the

Harkins D Carrel The Internet Key Ex D

following IPSec uses a shorter form of HMAC than

change IKE RFC Nov

SSL thus SSL data integrity is more secure SSL is

more compatible with rewall than IPSec unless IPSec

M ThomasJ Vilhub er Kerberized Internet Ne

and Firewall are integrated in the same device Unlike

gotiation of Keys KINK Internet Draft Jan

SSL IPSec clients need a sp ecial IPSec software for

remote access In low bandwidth networks or dialup

C Madson R Glenn The Use of HMACSHA networks using compression is b enecial SSL do esnt

within ESP and AHRFC Nov supp ort that PreShared scheme is easier to cong

ure and do esnt require any PKI infrastructureIPSec

C Madson R Glenn The Use of HMACMD

supp orts compression but unfortunately SSL do esnt

within ESP and AHRFC Nov

supp ort it IPSec is capable of protecting wireless net

works In most cases IPSec do esnt interop erate well

Y Sheer H Krawczyk Bernard Ab oba PIC

so b oth sides of the connection are required to havethe

APreIKE Credential Provisioning ProtocolIn

same vendors devices see table

ternet Draft Oct

S Beaulieu R p ereira Extended Authentica

Table IPSec vs SSL

tion within IKE XAUTH Internet Draft Oct

Function IPSec SSL

Conguration hard easy

wwwipagojpsecurityfyreport

Client Authentication must option

ipsechtml

PreShared Key yes no

Charlie Kaufman Internet Key Exchange

Interop erability Problem yes no

IKEv ProtocolInternet Draft Mar

TCP Application Supp ort all some

UDP supp ort yes no

G Huang S Beaulieu D Ro chefort A Trac

Throughput Rate high high

Based Method of Detecting Dead Internet Key Ex

Compression Supp ort yes Op enSSL only

change IKE PeersRFC Feb

HandshakeTime slow fast

T Kivinen A Huttunen B Swander V Volp e

Negotiation of NATTraversal in the IKE In

ternet Draft Feb

References

A Shacham B Monsour R Pereira M Thomas

IP Payload Compression Protocol IPCOMP

RFC Dec

Sheila Frankel Demystifying the IPSec Puzzle

Artec House Publisher

wwwopensslorg

Eric Rescorla SSL and TLS Designing and

Building Secure Systems AddisonWesley rd

Printing Aug

wwwfreeswanca

wwwstunnelorg

S Kent R Atkinson IP Encapsulating Security

Payload ESP RFC Nov

S Kent R Atkinson IP Authentication

HeaderRFC Nov