jurnal overhead ipsec 1

ARTICLE IN PRESS

Computer Networks xxx (2006) xxx–xxx

www.elsevier.com/locate/comnet

A generic characterization of the overheads imposedby IPsec and associated cryptographic algorithms

Christos Xenakis *, Nikolaos Laoutaris, Lazaros Merakos, Ioannis Stavrakakis

Communication Networks Laboratory, Department of Informatics and Telecommunications, University of Athens, Athens 15784, Greece

Received 6 May 2005; received in revised form 4 October 2005; accepted 9 December 2005

Responsible Editor: J. Misic

Abstract

This paper presents an assessment of the communication overheads of IPsec and evaluates the feasibility of deploying iton handheld devices for the UMTS architecture. A wide range of different cryptographic algorithms are used in conjunc-tion with IPsec, such as Data Encryption Standard (DES), Advanced Encryption Standard (AES), Message Digest (MD5)and Secure Hash Algorithm 1 (SHA-1). We consider the processing and packetization overheads introduced by these algo-rithms and quantify their impact in terms of communication quality (added delay for the end-user) and resource consump-tion (additional bandwidth on the radio interface). We conduct a quantitive analysis based on a detailed simulation modelof an IPsec enabled handheld device. We verify our simulation results by comparing against analytic results obtained froman approximate analytic model.� 2005 Elsevier B.V. All rights reserved.

Keywords: Security performances; Computational overhead; Space overhead; IPsec; DES; AES; MD5; SHA-1; Mobile devices

1. Introduction

Due to the intervention of the open-air medium,the transmission of data over wireless networks gen-erally requires a higher level of security than in wir-eline networks. The technology of Virtual PrivateNetworks (VPN) [1] has been used for the provisionof security services such as confidentiality, integrityand authentication in wireline and, lately, in wireless

1389-1286/$ - see front matter � 2005 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2005.12.005

* Corresponding author. Tel.: +30 210 7275418; fax: +30 2107275601.

E-mail addresses: [email protected] (C. Xenakis), [email protected] (N. Laoutaris), [email protected] (L. Merakos),[email protected] (I. Stavrakakis).

networks too. A VPN is used for the authenticationand the authorization of user access to corporateresources, the establishment of secure tunnelsbetween the communicating parties and the encap-sulation and protection of the data transmitted bythe network.

VPNs are usually implemented at the applicationor the network layer of a protocol stack. This paperconsiders the IPsec suit for deploying VPNs acrossIP networks. IPsec is a network layer security mech-anism that protects traffic on a per connection basisbetween network layer endpoints, and, thus, is inde-pendent from the applications that run above it.IPsec was originally developed for wireline IP

.

mailto:[email protected]





2 C. Xenakis et al. / Computer Networks xxx (2006) xxx–xxx

ARTICLE IN PRESS

networks, but it has also been used with wireless IPnetworks. In these environments, IPsec faces addi-tional challenges introduced by inherently limitedresources in the mobile devices and the wirelesschannels. Such limitations had not been consideredin the initial design of the suit. Thus an importantopen question is ‘‘is IPsec a feasible mechanismfor implementing VPNs over current and futureUMTS networks?’’ To answer this question, wequantify the space (increased bandwidth consump-tion due to security related additional informationon the transmitted packets) and time (increasedend-to-end delays due to security processing andincreased transmission time) overheads of IPsecand project their impact on the current technology.Such a projection will hopefully assist both themobile users and the network operators in establish-ing the price of the added VPN functionalitythrough IPsec and in choosing the appropriate suitconfiguration for their needs.

There is a rather limited literature on the over-heads introduced by IPsec [2–4]. A common limita-tion of existing works is that none of them seems tocontain all the currently employed security algo-rithms and also be independent of specific imple-mentations and platforms. This is precisely thegap that this article intents to fill. Elkeelany et al.[2] look at the processing overhead from employingData Encryption Standard (DES) (for confidential-ity) and Message Digest (MD5) Secure Hash Algo-rithm 1 (SHA-1) (for authentication security) inconjunction with IPsec. Our work extends this studyby jointly considering the Advanced EncryptionStandard (AES), which is not considered in [2].AES is quite important as it is the replacement ofDES and 3DES for confidentiality services. Milt-chev et al. [3] present a benchmark-based investiga-tion of the performance of IPsec in an OpenBSDsystem. The same work examines the benefits ofusing hardware accelerators for speeding up thecryptographic processing. Ganesan et al. [4] per-form an experimental evaluation of deployingsecurity algorithms such as, RC4, RC5, MD5 andSHA-1, on low-end embedded systems (AtmelAVR, Mitsubishi M16C, StrongARM, Xscale), aswell as on general-purpose systems (SPARC).

Our approach differs fundamentally with all pre-vious ones, in that we avoid making specific assump-tions regarding the underlying system, but rathermodel the induced overheads in a more abstractway. Our analysis is based on the structure and thefunctionality of the various algorithms and proto-

cols of IPsec. We quantify the number of basic pro-cessing operations required by each algorithm, aswell as the extra security fields introduced. The pecu-liarities of the underlying system technology (OS,processor, etc) are left out, since they change rapidlywith the shift of technology in both hardware andsoftware. Overall, our approach allows for an effec-tive and simple comparison of different configura-tions and algorithms of IPsec, independently ofspecific implementation and platforms. This bridgesthe gap between purely mathematical analysis andexperimental evaluations that target specific imple-mentations and assists in achieving the followingtwofold objective: (a) provide simulation and ana-lytic frameworks for assessing the processing andspace overheads introduced by IPsec; (b) identifypossible performance bottlenecks under some typi-cal deployment scenarios of handheld devices andthe UMTS radio interface protocol architecture.

The rest of this article is organized as follows.Section 2 presents an overview of IPsec and a quickreference to the most prominent ciphering algo-rithms used in conjunction with it. Sections 3 and4 analyze and quantify the processing and spaceoverheads, respectively, of the confidentiality andauthentication schemes employed by IPsec. Section5 presents the simulation model of an IPsec-equipped UMTS mobile device and the obtainedsimulation results. Section 6 describes the developedanalytic model. Section 7 concludes the article.

2. An overview of IPsec

IPsec [5] is a developing standard for providingsecurity at the network layer of the Internet. It facil-itates the authentication of the communicating enti-ties, allows them to set up secure IP channels fordata exchange, and provides a framework for theemployment of different cryptographic algorithmsdepending on the level of security required by theusers and their applications.

IPsec provides two choices of security servicethrough two distinct security protocols: the Authen-tication Header (AH) protocol [6], and the Encapsu-lating Security Payload (ESP) protocol [7]. The AHprotocol provides support for connectionless integ-rity, data origin authentication and protectionagainst replays, but it does not support confidential-ity. The ESP protocol supports confidentiality, con-nectionless integrity, anti-replay protection andoptional data origin authentication. Both AH andESP support two modes of operation: transport

C. Xenakis et al. / Computer Networks xxx (2006) xxx–xxx 3

ARTICLE IN PRESS

and tunnel. The transport mode of operation pro-vides end-to-end protection between the communi-cating end-points by encrypting the IP packetpayload. The tunnel mode encrypts the entire IPpacket (both IP header and payload) and encapsu-lates the encrypted original IP packet in the payloadof a new IP packet. This fact guarantees that no partof the initial IP packet is exposed to potentialthreats as the new IP packet is transmitted throughintermediate nodes of the network.

IPsec provides an open framework for incorpo-rating a wide range of different cryptographic algo-rithms for the actual cryptographic task oftransforming the original plaintext messages intothe transmitted ciphertext. Most ciphering algo-rithms that are used in conjunction with IPsec areiterative block ciphers. They break the original userdata packets into basic blocks of constant size,which are then encrypted independently through anumber of encryption rounds. The characteristicsof such ciphers depend on the choice of block size,key size and number of rounds. Larger block sizeslead to greater security, but on the other handreduce the encryption/decryption speed [8]. Simi-larly, larger keys lead to greater security, but alsodecrease the encryption/decryption speed. A ‘‘num-ber-of-rounds’’ parameter is usually used for speci-fying the number of repetitions of the basicencryption process on each basic block of data. Inthe remaining part of this section, the most promi-nent ciphering algorithms used in conjunction withIPsec are briefly presented.

The Data Encryption Standard (DES) algorithm[13] is a symmetric (shared secret key) block cipherwith block and key size of 64 bits (8 of the 64 bitsof the key are used for odd parity, reducing theeffective key length). Although widely used, DEShas been compromised on several occasions in thepast; in fact there exists specialized hardware forbreaking it in a few hours [9]. This has lead to theintroduction of triple DES (3DES), which is nomore than a triple repetition of the basic DESencryption: first the data block is DES-encryptedusing an initial key, then the encrypted block isdecrypted using a second (different) key and thenthe new block is re-encrypted using the initial key.This process is equivalent to using a larger effectivekey length of 112 bits. The obvious disadvantage of3DES is that it runs three times slower than DES onthe same platform.

The Rijndael algorithm, selected as the algorithmof choice for the new Advanced Encryption Stan-

dard (AES), [9,10,18], is one of the newest additionsto IPsec. Rijndael is a symmetric block cipher thatsupports different key and block sizes (128, 192, or256 bits). The AES standardized version of Rijnd-ael, however, is tied to a fixed block size of 128 bits.The initial block is passed through a round transfor-mation function, which is repeated 10 times (respec-tively, 12 or 14) under a key length of 128 bits(respectively, 192 or 256). Rijndael combines anincreased resistance against attacks with an imple-mentation simplicity and, thus, high execution rate.It has proved to be quite durable against differential,truncated differential, linear, interpolation, andSquare attacks, [9,11]. Rijndael is quite versatile asit may also serve as a Message Authentication Code(MAC) algorithm, as a hash function and as apseudo random number generator.

The Message Digest (MD5) [14] and Secure HashAlgorithm 1 (SHA-1), [15], implement so called‘‘one-way hash functions’’ and are usually used inconjunction with the above cryptographic algo-rithms for performing authentication. Both of themprocess input text blocks of 512 bits to generate 128-bit and 160-bit hash values, respectively, for the ver-ification of the correct message transfer. Both applypadding to make the plaintext a multiple of 512 bits,but they cannot be directly used as MAC algo-rithms, as they do not include a secret key. For thatreason, they are used in conjunction with keyed-Hashing for Message Authentication (HMAC),[16,17]. HMAC is a secret key authentication algo-rithm that provides a framework for incorporatingvarious hashing functions. The combined HMAC-MD5 and HMAC-SHA-1 mechanisms are in posi-tion to offer data origin authentication and integrityprotection services suitable for IPsec.

In the following two sections, the processing andspace overheads introduced by the above algorithmsin the framework of IPsec are examined, quantify-ing the impact of security on the underlying infra-structure when applying IPsec. These derivationsare used later to assess the feasibility of IPsecdeployment on mobile devices and networks, whichare characterized by limited processing power andbandwidth, respectively.

3. Quantification of the processing overheadof the confidentiality and authentication schemes

employed by IPsec

The IPsec suite entails significant processingwork for the encryption and decryption of user data


ARTICLE IN PRESS

(both of which are applied in a per-packet fashion)to assure the confidentiality and the authenticationof the exchanged information (through the compu-tation of integrity-check values (ICV)). Handhelddevices have still to operate under rather tight pro-cessing and energy constraints, (despite the continu-ous advances in CPU technology) as compared tothe fixed computing devices, for which the IPsecsuite was originally designed. Therefore, we firstneed to quantify the processing overheads imposedby the various protocols employed by the IPsec, inorder to assess the feasibility of its deployment onmobile devices. To this end, all processing require-ments will be expressed in terms of number ofCPU cycles, to facilitate a comparative performanceevaluation independently of specific implementa-tions and across different algorithms. The DES,3DES and AES (for confidentiality) and theHMAC-MD5 and HMAC-SHA-1 (for authentica-tion services) schemes will be investigated. Table 1summarizes the notation used in the analysis thatfollows.

3.1. DES, HMAC-MD5 and HMAC-SHA-1

The DES cipher uses a key of 56 bits, and a blockof 64 bits. Since DES is a Feistel cipher, it requiresthe same amount of processing for both encryptionand decryption. 3DES results from a triple execu-tion of DES and, thus, requires three times more

Table 1Notation definition

Symbol Description

CP Processor speed in MillioK Size of the extra appendeKey Size of a secret key shareKi,Ko Extended forms of the innk Number of input blocksNb,Nk,Nr Parameters of AES that

and number of iterationsSd Size of user data packetsp Size of the padding fieldss Size of the field that presTHMAC-MD5(nk), THMAC-SHA-1(nk) Total number of operatio

HMAC-SHA-1, respectivTDES,T3DES,TRij,TMD5,TSHA-1 Total number of operatio

MD5 and SHA-1, respecTa,To,Ts Number of operations re

OR and SHIFT respectivtDES(Sd,CP), t3DES(Sd,CP), tAES(Sd,CP) Time required by a proce

of the user packet size anUDES(Sd), U3DES(Sd), UAES(Sd),UHMAC-MD5(Sd), UHMAC-SHA-1(Sd)

Total number of operatioHMAC-MD5 and HMA

processing. Let TDES and T3DES denote the numberof operations required for encrypting one block ofuser data with DES and 3DES respectively. Theanalysis of the two ciphers that appears in [2] hasshown that TDES = 2697 and T3DES = 8091. Let Sd

denote the size of an unencrypted user data packetand let UDES(Sd) and U3DES(Sd) denote the corre-sponding numbers of operations required to encryptit with DES and 3DES. Then clearly,

UDESðSdÞ ¼8� Sd

64

� �� TDES; ð1Þ

U 3DESðSdÞ ¼8� Sd

64

� �� T 3DES ð2Þ

(de denotes the ceil function). Consider now aprocessor that can perform CP Millions InstructionPer Second (MIPS), and let tDES(Sd,CP) andt3DES(Sd,CP) denote the time required by thisprocessor for encrypting one user packet of lengthSd with DES and 3DES respectively. Then,

tDESðSd;CPÞ ¼8� Sd

64

� �� TDES

CP

; ð3Þ

t3DESðSd;CPÞ ¼8� Sd

64

� �� T 3DES

CP

. ð4Þ

Two common MAC algorithms used in the IPsecsuite are the combined HMAC-MD5 and HMAC-SHA-1, which have similar functionality. In bothalgorithms the hash computation and the hash ver-

ns Instructions Per Second (MIPS)d inner form of the key in MD5 and SHA-1 (512 bits)d by a sender and a receiver (bits)put Key (512-bit)for the inner MD5 and SHA-1 algorithmare related to the block size, key lengthrespectively(bytes)used in MD5 and SHA-1 (bits)ents the message length in MD5 and SHA-1 (bits)ns required for applying HMAC-MD5 andely, as a function of the number of input blocksns per block required for applying DES, 3DES, AES,tivelyquired by a processor for applying a basic byte-wise AND,elyssor for applying DES, 3DES and AES processing as a functiond the processor speedns required by a processor for applying DES, 3DES, AES,C-SHA-1 processing as a function of the user packet size


ARTICLE IN PRESS

ification are equivalent procedures and, thus, re-quire the same amount of processing. The first stepin both the MD5 and SHA-1 algorithms is to padthe original message and make its size a multipleof 512 bits, where the last 64 bits of the last blockindicate the length of the message. Subsequently,the algorithms produce a 128-bit and a 160-bitshash values, respectively, of which only a truncated96-bit portion is used by IPsec. The total number ofoperations required for MD5 processing per block(512 bits), TMD5, is 720 plus 24 operations forinitialization and termination, while for SHA-1processing, TSHA-1, is 900 plus 210 operations forinitialization and termination [2].

The combined HMAC-MD5 and HMAC-SHA-1algorithms are formulated as follows:

MD5ðKo;MD5ðK i; TextÞÞ;SHA-1ðKo; SHA-1ðK i; TextÞÞ;where

K i ¼ Key � ipad;

Ko ¼ Key � opad;

Ki and Ko are two extended forms (512-bit) of theinput Key, which are generated by ‘‘exclusive oring’’the Key with ipad (the inner padding (512 bits)) andopad (the outer padding (512 bits)) respectively. Keyis an arbitrary size secret key shared by a sender anda receiver, and � denotes the XOR operation.

For a user packet of size Sd bytes, the number ofinput blocks for the inner MD5 and SHA-1, nk, is

nk ¼8� Sd þ sp þ ss þ K

512

� �;

where sp is the size (in bits) of the padding field,ss is the size (in bits) of the field that specifies themessage length, and K is the size (in bits) of theextra appended inner form of the key.

In the outer MD5 and SHA-1, the output of theinner MD5 (128-bit digest) and SHA-1 (160-bitdigest), respectively, are appended to Ko and, then,are padded to two 512-bit blocks. Thus, the totalnumber of operations in applying the combinedHMAC-MD5 and HMAC-SHA-1, THMAC-MD5(nk),U

HMAC-MD5(Sd), THMAC-SHA-1(nk), and, UHMAC-SHA-1

(Sd) as a function of the number of input blocksnk, and the user packet size Sd, are

THMAC-MD5ðnkÞ ¼ 32þ ð2þ nkÞ � 744; ð5Þ

UHMAC-MD5ðSdÞ ¼ 2264þ 744� ð8� SdÞ þ 64

512

� �� ;

ð6Þ

THMAC-SHA-1ðnkÞ¼32þð2þnkÞ�1110; ð7Þ

UHMAC-SHA-1ðSdÞ¼3362þ1110� ð8�SdÞþ64

512

� �� .

ð8Þ

The factor 32 in Eqs. (5) and (7) derive from theXOR operations performed to produce the innerand the outer keys, Ki and Ko. Specifically, it resultsfrom the division of the size of XOR operands (512bits) by the word length supported by the processor(i.e. it is assumed to be 32 bits). The outcome of thedivision (i.e., 16) is multiplied by 2, as the XORoperation occurs twice (one for Ki and one forKo). Finally, the required authentication and verifi-cation time for HMAC-MD5, tHMAC-MD5(nk,CP),and HMAC-SHA-1, tHMAC-SHA-1(nk,CP), as a func-tion of the number of input blocks and the proces-sor speed, are

tHMAC-MD5ðnk;CPÞ ¼32þ ð2þ nkÞ � 744

CP

; ð9Þ

tHMAC-SHA-1ðnk;CPÞ ¼32þ ð2þ nkÞ � 1110

CP

. ð10Þ

3.2. AES

Rijndael is an iterated block cipher with a blockof length 4Nb bytes (or Nb (32-bit) words) and a var-iable key of length 4Nk bytes. The encryption ofeach block of the data involves the following: (a)an initialization phase; (b) Nr � 1 iterations of thebasic encryption processing of the algorithm; (c) afinalization phase. The version of the Rijndael algo-rithm that was integrated as part of the AES encryp-tion standard [18] uses a block of 128 bits (i.e.,Nb = 4) and a key of 128, 192, or 256 bits (i.e.,Nk = 4, 6, or 8). Depending on the selected keylength, the AES standard defines the number ofrounds for phase (b) as follows: Nr(128) = 10,Nr(196) = 12, Nr(256) = 14. In [19] the authors haveanalyzed the Rijndael encryption and have derivedsimple expressions for TRij, the computational effortrequired for encrypting one block of data with thisparticular cipher. They have expressed this compu-tational effort as a function of the block size, thekey size, and the number of processing cyclesrequired for performing basic operations such as abyte-wise AND (Ta), a byte-wise OR (To), and abyte-wise shift (Ts). The resulting general expressionis


ARTICLE IN PRESS

TRij-ENC ¼ ð46NbNr � 30NbÞT a

þ ½31NbNr þ 12ðNr � 1Þ � 20Nb�T o

þ ½64NbNr þ 96ðNr � 1Þ � 61NbÞ�T s.

By assuming that each basic operation requires oneprocessing cycle, i.e., Ta = To = Ts = 1, we can de-rive the corresponding number of processing cyclesrequired for encrypting one block of data with eachone of the three standardized flavours of AES (fordifferent key lengths):

TAES-ENCð128Þ ¼ 6168;

TAES-ENCð192Þ ¼ 7512;

TAES-ENCð256Þ ¼ 8856.

Using the same definitions and notation as withDES and 3DES, we can write

UAES-ENCðSdÞ ¼8� Sd

128

� �� TAES-ENC ð11Þ

and,

tAES-ENCðSd;CPÞ ¼8� Sd

128

� �� TAES-ENC

CP

; ð12Þ

where TAES-ENC can take either of the following val-ues TAES-ENC (128), TAES-ENC (196), or TAES-ENC

(256), depending on the selected key length.An important difference of Rijndael as compared

to other ciphers such as DES and 3DES, is thatRijndael has a non-Feistel structure, meaning thatthe decryption process makes use of partially differ-ent code, which allows for only partial re-use of theencoding circuitry that implements the cipher. Theimplementation differences are identified in phase(b) of the decryption code, and in particular in theInvMixColumns operation, which uses a differentpolynomial structure as compared to the corre-sponding MixColumns operation of the encryptioncode and, thus, leads to an increased complexityfor the decryption. By using the analysis presentedin [19], we can obtain an expression for the numberof processing cycles for decrypting one block ofdata.

TRij-DEC ¼ TRij þ 96NbT a þ ðNr � 1Þ� ð72NbT o � 32NbT sÞ. ð13Þ

The above expression (Eq. (13)) points to the factthat the Rijndael decryption is computationallymore expensive than the encryption (the actual dif-ference being 96NbTa + 72NbTo � 32NbTs opera-tions for each of the Nr � 1 rounds of phase (b)).Using this expression, we can obtain the corre-

sponding number of processing cycles required fordecrypting one block of data with each one of thethree standardized flavours of AES (for differentkey lengths):

TAES-DECð128Þ ¼ 10992;

TAES-DECð192Þ ¼ 13408;

TAES-DECð256Þ ¼ 15824.

ð14Þ

From these values, we can obtain UAES-DEC(Sd) andtAES-DEC(Sd) similarly to the encryption case. Noticethat the number of operations required for thedecryption is significantly higher than for theencryption. Thus, there have been some efforts forreducing this asymmetry through faster implemen-tations (see for example [19–21]).

4. Quantification of the space overheadof the confidentiality and authentication schemes

employed by IPsec

Both ciphering and the IPsec packetizationincrease the final size of the transmitted packets,thereby creating space overhead. The ciphering over-head is created by padding the original packet inorder to make its size a multiple of the basic blocksize of the ciphering algorithm. The IPsec packetiza-tion overhead is created by the additional IPsec-specific fields that are added to the protected IPpackets.

The IPsec packetization overhead depends on theselected security protocol. Fig. 1(a) presents the for-mat of an ESP protocol packet. The ESP header,which includes the security parameters index andthe sequence number fields, is inserted into the IPpacket immediately prior to the transport-layerheader. The ESP trailer, which contains the pad-ding, the pad length, and the next header fields, isplaced after the IP packet. When the authenticationservice of IPsec is selected, an additional field—theESP authentication data field—is added after theESP trailer. Therefore, the space overhead that cor-responds to the ESP security protocol consists of: (i)the fixed-size fields (10 bytes), (ii) the optionalauthentication data field (12 bytes), and (iii) the var-iable length padding applied (that ranges from 0 to8 bytes). Fig. 1(b) presents the format of the AHprotocol header. The header consists of the fixed-size fields (i.e., Next header, payload length,reserved, security parameter index, and sequencenumber) (12 bytes) and the field of authenticationdata (12 bytes).

Fig. 1. The format of (a) an ESP protocol packet and (b) the AH protocol header.


ARTICLE IN PRESS

The operation mode of IPsec and the supportedsecurity services (authentication, confidentiality, orcombined) are also contributing to the space over-head. In transport mode the aforementioned IPsec-specific fields (i.e., ESP header, AH header, ESPtrailer and authentication data field) are insertedwithin the transmitted IP packet as shown inFig. 2(a). Thus, the total space overhead per-packetfor the AH protocol is 24 bytes, and for the ESPprotocol is 10 bytes plus the variable length ofthe padding field for confidentiality service, and22 bytes plus the variable length of the paddingfield for combined confidentiality and authentica-tion services. On the other hand, in tunnel mode,a new IP header is added in each IPsec-protectedpacket in addition to the IPsec-specific fields(Fig. 2(b)), which leads to a higher space overheadthan in transport mode. The total space overhead isthus given by the sum of the above values (trans-port mode) and the size of the new IP header (20bytes).

Original IP

PayloadTCPhdr

Orig IPhdr

PayloadTCPhdr

AHhdr

Orig IPhdr

ESPauth

ESPtrl

PayloadTCPhdr

ESPhdr

Orig IPhdr

ESPtrl Payload

TCPhdr

ESPhdr

Orig IPhdr

AH protocol for authentication

ESP protocol for confidentiality

ESP protocol for authentication and confidentiality

(a)

Fig. 2. The packet format of AH and ESP protocol in

The previous discussion allows us to express thespace overhead of IPsec as a function of the userpacket size Sd, and elaborate specific formulas.The formulas present the size of protected packetfor both security protocols (ESP and AH) that areconfigured to provide confidentiality (CNF),authentication (ATH), and combined confidential-ity and authentication (CNF-ATH) security servicesin both modes of IPsec operation. Let SPX�Y(Sd),and SLX�Y(Sd), denote the size of protected packetsusing the protocol X (ESP or AH) that provides Y(CNF, ATH, or CNF-ATH) security services. Theemployed security algorithms are selected from theset of the analyzed ciphers (i.e., DES, 3DES AES,HMAC-MD5 and HMAC-SHA-1). Table 2explains the notation used in the formulas, andTable 3 presents the details of the formulas.

The next section of this paper presents a simula-tion study that attempts to assess the feasibility ofIPsec deployment on mobile devices and networks.The simulation model incorporates the analyzed

Payload TCPhdr

Orig IPhdr

Original IP

PayloadTCPhdr

Orig IPhdr

AHhdr

New IPhdr

AH protocol for authentication

ESPtrl

Payload TCPhdr

Orig IPhdr

ESPhdr

New IPhdr

ESPauth

ESPtrl Payload

TCPhdr

Orig IPhdr

ESPhdr

New IPhdr

ESP protocol for confidentiality

ESP protocol for authentication and confidentiality

(b)

(a) transport and (b) tunnel mode of operation.

Table 2Notation definition

Symbol Description

AuTESP Size of the authentication data field of the ESP protocol (12 bytes)Bl Block size of the encryption algorithms (8 bytes for DES, and 16 bytes for AES)HESP, HIP, HTCP Size of the ESP header (8 bytes), the IP header (20 bytes), and the TCP header (20 bytes), respectivelyRP(Sd), RL(Sd) Ratio of the actual payload to the total packet length, as a function of user packet size for transport

and tunnel mode of operation respectivelySd User packet size (bytes)SP(Sd), SL(Sd) Size of IPsec-protected packets as a function of user packet size for transport and tunnel mode

of operation respectively (bytes)TrESP Size of the fixed part of the ESP trailer (2 bytes)

Table 3Formulas that give the size of protected packets as a function of user packet size for different configurations of IPsec

Notation Description formula Final formulaa

SPESP-CNF(Sd)SdþHTCPþTrESP

Bl

� �� Blþ HESP þ H IP

Sdþ22Bl

� �� Blþ 28

SLESP-CNF(Sd)SdþHTCPþH IPþTrESP

Bl

� �� Blþ HESP þ H IP

Sdþ42Bl

� �� Blþ 28

SPESP-ATH(Sd)SdþHTCPþTrESP

4

� �� 4þ HESP þ H IP þ AuT ESP

Sdþ224

� �� 4þ 40

SLESP-ATH(Sd)SdþHTCPþH IPþTrESP

4

� �� 4þ HESP þ H IP þ AuT ESP

Sdþ424

� �� 4þ 40

SPESP-CNF-ATH(Sd)SdþHTCPþTrESP

Bl

� �� Blþ HESP þ H IP þ AuT ESP

Sdþ22Bl

� �� Blþ 40

SLESP-CNF-ATH(Sd)SdþHTCPþH IPþTrESP

Bl

� �� Blþ HESP þ H IP þ AuT ESP

Sdþ42Bl

� �� Blþ 40

SPAH(Sd) (Sd +HTCP +HIP + 24) (Sd + 64)

SLAH(Sd) (Sd +HTCP + 2 ·HIP + 24) (Sd + 84)

a The final formula is derived after substituting the values of the variables and performing some additional simple algebraicmanipulation.


ARTICLE IN PRESS

models for processing and space overhead andsubjects them to typical data traffic [22].

5. Simulation study

Fig. 3 depicts a block diagram of the IPsec-equipped MS that is considered in the following sim-ulation study. The model consists of the followingcomponents: (i) a traffic generator for the creationof non-real time traffic at the network layer accord-ing to the parameters that are defined in a next par-agraph; (ii) an IPsec/IP processor queue where

TCP

L1

RLC

MAC

PDCPIPsec processor

IPsec /IP

GeneratorGenerator

GeneratorStatistics

Fig. 3. Model of an IPsec-equipped MS.

packets accumulate before entering the processorthat applies the cryptographic algorithms and thefunctionality of IPsec/IP according to the selectedmode of operation of IPsec; and (iii) a transmittermodule that incorporates the radio interface proto-col architecture of UMTS in the user plane.

The transmitter module is further divided intofour layers: the physical layer (L1), the MediumAccess Control (MAC), the Radio Link Control(RLC) and the Packet Data Convergence Protocol(PDCP). The physical layer is responsible for theForward Error Correction (FEC) of transport chan-nels (channel coding), error detection using CyclicRedundancy Code (CRC) and RF processing. TheFEC scheme aims at detecting and recovering fromtransmission errors by adding information in thepackets that can be used for their reconstructionat the receiver. It is implemented by employing aconvolutional code that introduces 1/2 code rate,which indicates the space overhead of the coder(the output of the coder is twice as many bits usedfor input). The channel coding (FEC) is combinedwith a CRC error detection function that verifies

Table 4Simulation parameters setting

Simulation parameters Base values

Mean data rate kdata 128 Kbit/s–1.2 MbpsMS processing speed CMS 100–500 MIPSAverage size of datagram ln 480 bytesRadio channel capacity 2 MbpsPacket error rate (PER) 2%


ARTICLE IN PRESS

the results of FEC. Using this function, erroneouspackets are detected and indicated to higher layers(RLC) for retransmission. The length of the CRCpolynomial used is 16 bits [23].

On top of the physical layer the MAC and RLCprovide link layer functionality. TheMAC layer pro-vides logical channels to the RLC and maps logicalchannels into transport channels using the non-transparent transmission mode [24]. The RLC layerprovides an acknowledged mode of data transferby employing an Automatic Repeat Request(ARQ) mechanism. This mechanism tries to recovererrors by retransmitting flawed packets indicated bythe physical layer (error detection function) [25] andthus putting additional load on the radio interface.Finally, the PDCPmaps the IP layer to the RLC [26].

The employed simulated traffic represents non-real time user traffic according to the referencemodel defined by the 3GPP in [22]. It is assumedthat there exists an active user that generates packetsessions. Each session involves bursty sequences ofpackets. The mean user data rate is denoted kdataand ranges from 128 Kbit/s to 1.2 Mbit/s. Packetinter-arrival times between subsequent user packetsin a packet call are modeled by an i.i.d. random var-iable that follows an exponential distribution withparameter ld. The sizes of user packets are modeledby an i.i.d. random variable Sd that follows thetruncated Pareto distribution fSdðxÞ:

fSdðxÞ ¼aka

xaþ1 ; k 6 x < l;km

� �a; x ¼ l.

(ð15Þ

The parameters k andm define the minimum and themaximum user data packets respectively and theparameter a defines the skewness of the distribution(the default values are a = 1.1, k = 81.5 bytes andm = 66666 bytes [22]). The average packet size isln = 480 bytes and the radio channel capacity is2 Mbps (total rate including all the management andcontrol information). The packet error rate (PER)parameter over the radio interface, which also indi-cates the percentage of retransmissions at the RLClayer, is 2%. The mobile device is assumed to beequipped with an embedded processor with a pro-cessing rate Cp in the range of 100–500 Millions ofInstructions Per Second (MIPS) [27]. Table 4 sum-marizes the values of the basic simulationparameters.

A total of fifty-three (53) different security scenar-ios are considered. They include: (i) the two differentmodes of operation of IPsec (transport and tunnel);

(ii) the two different protocols of IPsec (ESP andAH); (iii) several different cryptographic algorithmsthat provide different levels of security: no security,pure confidentiality (DES, 3DES and AES with var-iable key length for the encryption and decryptionprocess), pure authentication (MD5 and SHA-1),and combined confidentiality and authentication(DES+MD5, 3DES+MD5, DES+ SHA-1, 3DES+SHA-1, AES(128)Enc + MD5, AES(128)Enc +SHA-1, AES(192)Enc + MD5, etc). The evaluationof the different scenarios is based on the followingperformance metrics: (i) the system throughput, (ii)the packet latency, and (iii) the data rate increasedue to IPsec. In the next paragraphs we summarizeour observations from the simulation experiments.The parameters that will be examined in the follow-ing simulations include: the offered traffic load, theservice rate of the IPsec/IP processor queue, andthe characteristics of the radio interface.

In the majority of the employed security scenar-ios, the encryption and decryption are symmetricprocesses and, thus, they consume the same amountof processing. For that reason we have selected todevelop a simulation model that represents onlythe IPsec encryption, and use it as a basis for theaccomplished performance evaluation and the com-parison of the different security scenarios. However,as mentioned previously (Section 3.2), the AEScipher has a non-Feistel structure and the decryptionis computationally more expensive than encryption.Thus, both AES processes (encryption and decryp-tion) with all the possible key lengths (i.e., 128,192, 256) are applied to the developed simulationmodel. This fact facilitates the assessment of thecomputational difference between the encryptionand the decryption process in AES, and the compar-ison of both AES processes with the rest of theemployed ciphering algorithms.

5.1. System throughput

Fig. 4 depicts the system throughput as a func-tion of the processing speed of the MS for the above


ARTICLE IN PRESS

security scenarios. The IPsec mode of operation hasa negligible effect on the system throughput and,thus, the presented diagrams represent both modesof operation. One may observe that the more ‘‘light-weight’’ security schemes like MD5, SHA-1, DES,DES + MD5 and DES + SHA-1 do not degradethe system throughput, as they add a rather limitedamount of processing (see Fig. 4(a)). This points tothe fact that a processing rate of 100 MIPS andabove should be enough for handling the addedprocessing of these lightweight schemes. For theabove combinations of security schemes and pro-cessing rates, the bottleneck in terms of throughputis dictated by the capacity of the radio channel.More complex security schemes like 3DES,3DES + MD5 and 3DES + SHA-1 provide for anincreased resistance against attacks but pose higherprocessing requirements and, thus, reduce the sys-tem throughput when the MS processing rate isbelow 300 MIPS (which appears to be the border-line minimum for employing these schemes).

Regarding AES, although it requires less process-ing than 3DES, it also lowers the system throughputwhen there is not sufficient processing capability atthe MS (see Fig. 4(b)). The throughput of theencryption process of AES presents higher valuescompared to the decryption. The lightest flavor ofAES, i.e., the one that provides encryption with akey length of 128 bits, has almost no effect on thesystem’s throughput. Increasing the key length,however, puts more strain on the processor and thiscan translate into reduced throughput in cases thatthe MS processing rate is bellow 300 MIPS (which

0

200

400

600

800

1000

12003DES+MD53DES+SHA13DES

Sys

tem

Thr

ough

put (

Kbp

s)

Millions Instruction Per Second in MS (MIPS)

100 - 500 500

400

300

200

100

500

400

300

200

100

DES+SHA1

DES+MD5

DESSHA1

MD5

No Sec

urity

(a)

Fig. 4. System throughput as a function of the processing speed of thscenarios like (a) no security, MD5, SHA-1, DES, DES +MD5, DES +different key size for both encryption and decryption process.

also appears to be the boarder for employingAES). Combining confidentiality with authentica-tion services by adding MD5 or SHA-1 to AESincreases even more the strain on the processor.This extra strain is, however, relatively small ascompared to the one imposed by the encryptionscheme and thus is hardly visible on the figures.

5.2. Total delay

Except for its impact on the system’s throughput,a security scheme increases the total delay for trans-mitting a user packet. Fig. 5 shows the total delay asa function of the user data rate for the various secu-rity schemes and a processing rate of 100 MIPS.Sole application of authentication services, likeMD5 and SHA-1, hardly has an impact on the totaldelay (see Fig. 5(a)). DES encryption presentshigher delay values than authentication services,but its application on the system does not consider-ably influence the data transfer. On the contrary,AES encryption and decryption with a 256 bit keylength (labeled AES(256)Enc and AES(256)Dec,respectively, in the corresponding figure) and3DES have stronger impact on the total delay.Moreover, these scenarios under sufficiently highuser data rates lead to excessive delay values, whichpoint to the fact that the user data rate has exceededthe maximum capacity of the MS.

Fig. 5(b) presents the total delay values for thevarious configurations of the AES algorithm in theframework of IPsec. The simulation results haveverified that the decryption process of AES presents

0

200

400

600

800

1000

1200

Sys

tem

Thr

ough

put (

Kbp

s)

Millions Instruction Per Secondin MS (MIPS)

200

AES(256

) Dec

AES(192

) Dec

AES(128

) Dec

200

- 50010

0

AES(256

) Enc

AES(192

) Enc

100

-500

AES(128

) Enc

100

200

- 500 10

0

200

- 500 10

0

300

- 500 10

020

0

300

- 500

(b)

e MS for both modes of IPsec operation, and different securitySHA-1, 3DES, 3DES +MD5 and 3DES + SHA-1, (b) AES with

0 200 400 600 800 10000

200

400

600

800

1000

1200

1400

1600

1800

2000

2200

2400

Processing capabilities 100 MIPS

Data rate (kbps)

No Security

MD5 or SHA1

DES

AES(256) Enc

AES(256) Dec

3DES

0 200 400 600 800 10000

200

400

600

800

1000

1200

1400

1600

1800

2000

2200


Mea

n pa

cket

del

ay (

ms)

Data rate (kbps)

No Security

AES(128) Enc

AES(192) Enc

AES(256) Enc

AES(128) Dec

AES(192) Dec

AES(256) Dec

(a) (b)

Fig. 5. Mean total delay as a function of mean data rate for 100 MIPS processing rate at the MS and (a) MD5, SHA-1, DES, AESencryption and decryption with a 256 bit key and 3DES (b) AES encryption and decryption with variable key length.

0 200 400 600 800 10000

200

400

600

800

1000

1200

1400

1600

1800Processing capabilities 100 MIPS

No Security

DES

DES+SHA

AES(128) Enc

AES(128) Enc + SHA

Mea

n pa

cket

del

ay (

ms)

Data rate (kbps)

Fig. 6. Mean total delay as a function of mean data rate for 100MIPS processing rate at the MS and DES, DES + SHA-1,AES(128)Enc and AES(128)Enc + SHA-1.


ARTICLE IN PRESS

higher delay values than encryption. Moreover, theyhave verified that as the size of the key used by AESincreases, the algorithm execution becomes morecomplex resulting in a higher delay values for datatransfer. Thus, the plotted delay values quantifythe processing differences of the different optionsof AES algorithm in the framework of IPsec inthe considered environment.

Fig. 6 presents the total delay of the combinedconfidentiality and authentication security servicesusing DES + SHA-1 and AES(128)Enc + SHA-1algorithms, as a function of the user data rate andfor a processing rate of 100 MIPS. It comparesthe above total delay values to the total delay ofthe pure confidentiality security services usingDES and AES(128)Enc algorithms, respectively.Observed that the addition of authentication secu-rity services hardly increases the total packet delayvalues, since authentication represents a relativelylightweight (from the processing overhead point ofview) security service. In addition, Fig. 6 shows thatDES and AES encryption with 128-bit key have asimilar behavior and add marginally to the totaldelay as compared to the no-security scenario. Thesource data of Fig. 6 as well as the confidence inter-vals are presented in the table included in AppendixA of this paper.

For a greater MS processing rate of 200 MIPS,there is a similar qualitative behavior as with theabovementioned 100 MIPS case. However, theabsolute delay values become smaller, owing tothe shorter time spent on the IPsec/IP processorqueue. In fact, with such a processing rate, someof the lightweight security schemes incur a total

delay that approaches the one of the no security sce-nario (see Fig. 7(a)). Increasing the MS processingrate further to 500 MIPS (Fig. 7(b)) pushes thedelay curves of the various security schemes veryclose to the no security curve, which means that inthis case IPsec has almost a negligible impact onthe system’s performance with respect to the delay.

5.3. Rate increase of the protected data

Apart from the processing overhead due to theIPsec/IP processor queue, a security mechanismadds an additional space overhead by increasingthe size of the final transmitted user packets. Theincrease owes to the extra security fields encapsu-lated with the user data in the final packets, and

0 200 400 600 800 1000 12000

200

400

600

800

1000

1200

1400

1600

1800

2000


Data rate (kbps)

No Security

MD5 or SHA1

DES

AES(256) Enc

AES(256) Dec

3DES

0 200 400 600 800 10000

200

400

600

800

1000

1200

1400

1600


Mea

n pa

cket

del

ay (

ms)

Data rate (kbps)

No Security

MD5 or SHA1

DES

AES(256) Enc

AES(256) Dec

3DES

(a) (b)

Fig. 7. Mean total delay as a function of mean data rate for MD5, SHA-1, DES, AES(256)Enc, AES(256)Dec and 3DES and (a) 200(b) 500 MIPS processing rate at the MS.


ARTICLE IN PRESS

has the natural effect of increasing both the packettransmission time and the final output rate (therebyconsuming more bandwidth on the wireless chan-nel). Fig. 8 depicts the rate increase of the protecteddata as a function of the actual user data rate. Aswas expected from the discussion of the space over-head of IPsec (Section 4), the tunnel mode of oper-ation leads to a higher overhead than the transportmode. One may observe that for each mode of oper-ation of IPsec, the confidentiality services (usingAES or DES or 3DES) impose the same rateincrease; the slight difference between the spaceoverhead of AES and DES (3DES) causes a negligi-ble difference to the rate increase of the protecteddata. The same applies among the pure authentica-tion, and the combined authentication and confi-dentiality security services (i.e., MD5, SHA-1,

200 400 600 800 1000

0

2

4

6

8

10

12

14

Rat

e in

crea

se o

f the

pro

tect

ed d

ata

(Kbp

s)

Data rate (kbps)

AES or DES or 3DES in transport mode

MD5 or SHA-1 or DES+MD5 in transport mode

AES or DES or 3DES in tunnel mode

MD5 or SHA-1 or DES+MD5 in tunnel mode

Fig. 8. Rate increase of the protected data as a function of theactual data rate for various security services.

DES + MD5, AES + SHA-1, etc.). The confidenti-ality security services impose the lowest rate increaseof the protected data; while the pure authenticationsecurity services and the combined confidentialityand authentication services impose the highestincrease to the final output rate.

6. Analytic model of an IPsec-equipped MS

In this section we develop a simple analyticmodel for the abstract MS that is depicted inFig. 9. The analysis is carried out by modeling theIPsec processor and the transmitter as a system oftwo independent M/G/1 queues in tandem. Theanalysis aims at both verifying the simulation resultsand providing a faster alternative to them.

6.1. First queue (IPsec processor)

The first queue is an M/G/1 queue with the fol-lowing characteristics: (i) a Poisson arrival processof rate k for modeling the arrivals of data packetsfrom the user; (ii) i.i.d. service times X1 withexpected value E{X1} and expected square valueEfX 2

1g. Let l1 denote the constant service rate ofthe server of the first queue (to be defined in detailshortly). Then E{X1} and EfX 2

1g can be written as

IPsec processor

GeneratorGeneratorGeneratorStatisticsTCP

IPsecIP TCP Trx

Transmitter

Fig. 9. Analytic model.

1 Such approximations are known to be leading to a smalleraverage delay than the actual system of two queues in tandemand this is also the case in our results here [12].


ARTICLE IN PRESS

functions of l1 and fSdðxÞ, the probability densityfunction of user packets which, as with Section 5,are assumed to be following a truncated Paretodistribution with parameters k, m, a. Thus,

EfX 1g ¼Z m

k

xl1

fSdðxÞdx

¼ aðmka � kmaÞmal1ð1� aÞ þ mðk=mÞa=l1; ð16Þ

EfX 21g ¼

Z m

k

xl1

� �2

fSdðxÞdx

¼ aðm2ka � k2maÞmal2

1ð2� aÞ þ m2ðk=mÞa=l21. ð17Þ

Let W1 denote the mean total delay at the firstqueue (queuing and transmission components); W1

is given by the well known Pollaczek–Khinchin(P–K) formula, i.e.,

W 1 ¼ EfX 1g þkEfX 2

1g2ð1� kEfX 1gÞ

. ð18Þ

The service rate l1 of the IPsec processor queue de-pends on: (i) the speed of the processor (Cp) ininstructions per second; (ii) the block-size NX usedby the employed cryptographic algorithm X forencrypting user data (iii) the number of instructionsrequired by the cryptographic algorithm X forencrypting one block of user data of size NX (inthe previous section this quantity has been denotedTX). The exact relationship giving l1 is l1 = (NX/8)(Cp/TX). An important observation with regard tothe expression of E{X1} and EfX 2

1g is that a userpacket of size x requires the processing of dx/Nbeblocks of data under a block-cipher with block sizeNb. In order to simplify the derivation, we have ne-glected the ceiling function and, thus, the analyticmodel may account for up to minus one blocksper user packet. As will be shown later, this approx-imation has a rather minor effect on the accuracy ofthe model and, thus, is worth performing it in orderto simplify the analysis.

6.2. Second queue (transmitter)

The arrival process of the transmitter queue isgiven by the output process of the IPsec processorqueue and, thus, is no longer a Poisson process.We will employ an independence approximation andassume it to be Poisson nevertheless. The basis formaking this assumption is that under heavy loadconditions and highly variable service times at thefirst queue, the independence approximation can

produce usable results in terms of accuracy.1 Theaforementioned conditions hold to a large extenttrue for our application and, thus, as will be shownin the sequel, the numerical results from our approx-imate analytic model compare favourably to the sim-ulations results of the actual system. This makes theapproximate analytic model a useful tool for con-ducting a first qualitative analysis of an IPsec-equipped MS without having to resort to laborioussimulations. More security schemes (possibly futureones) and different parameter sets can thus be evalu-ated quickly without needing a simulation study.

Under the above-mentioned approximation, thesecond queue becomes too an M/G/1 queue withthe same Poisson arrival process and i.i.d. servicetimes X2 that correspond to the time that is requiredfor transmitting the IPsec-protected user packetsover the wireless link. To write E{X2} and EfX 2

2gwe will take into consideration the following facts:(i) the wireless channel has a constant transmissionrate of l2 bytes per second and (ii) the user datapackets have sizes that correspond to a truncatedPareto distribution. For the second queue, however,the truncated Pareto distribution will be a shiftedversion of the original one (the shifting being onthe x-axis), because each transmitted packet hasan additional space overhead of R bytes due tothe encryption related information inserted by theemployed security scheme and the various headersadded by the four layers of the transmitter protocolstack (PDCP/RLC/MAC/L1). Thus,

EfX 2g¼Z m

k

xþRl2

fSdðxÞdx

¼kaðma�RþaRÞ�maðkaþR�aRÞmal2ð1�aÞ þðmþRÞðk=mÞa

l2

;

ð19Þ

EfX 22g¼

Z m

k

xþRl2

� �2

fSd ðxÞdx

¼ AþBþCmal2

2ð1�aÞða�2ÞþðmþRÞ2ðk=mÞa

l22

. ð20Þ

The parameters A, B and C used in Eq. (20) are asfollows:

A¼�3akaR2þ kaR2a2þ2kaR2�m2kaaþ kaa2m2þ2kaRa2m;

B¼�4mkaRaþ3maR2a�maR2a2�2maR2þmaak2�maa2k2;

C¼�2maRa2kþ4maRak.

0 200 400 600 800 1000

0

200

400

600

800

1000

1200

1400

1600


Mea

n pa

cket

del

ay (

ms)

Data rate (kbps)

DES - Simulation

DES - Analytical

AES(256) Enc - Simulation

AES(256) Enc - Analytical

3DES - Simulation

3DES - Analytical

0 200 400 600 800 1000

0

200

400

600

800

1000

1200

1400Processing capabilities 200 MIPS

Mea

n pa

cket

del

ay (

ms)

Data rate (kbps)

DES - Simulation

DES - Analytical



3DES - Simulation

3DES - Analytical

(a) (b)

0 200 400 600 800 10000

200

400

600

800

1000

1200


Mea

n pa

cket

del

ay (

ms)

Data rate (kbps)

DES - Simulation

DES - Analytical



3DES - Simulation

3DES - Analytical

(c)

Fig. 10. Total delay obtained from the analytical and the simulation model as a function of the actual data rate for DES, AES(256)Encand 3DES security scenarios and for (a) 100 MIPS (b) 200 MIPS and (c) 500 MIPS processing rate at the MS.


ARTICLE IN PRESS

We can now use the P–K formula in order to com-pute W2, the mean total delay at the second queue.In doing so, we take notice to increase the input ratek by 2% in order to account for packet retransmis-sions by the RLC layer of the transmitter. The over-all delay (encryption and transmission components)is then taken from W = W1 + W2.

In Fig. 10 we plot the total delay obtained fromthe above analysis against the one obtained fromthe simulation experiments of the previous section.We show results for 100, 200 and 500 MIPS forsome indicative scenarios such as DES,AES(256)Enc and 3DES. One may easily concludethat the analytic results capture satisfactorily thequalitative behavior in terms of the delay. Observe,however, that the absolute delay values are lower inthe analysis than in the simulation. This is in accor-

dance to our expectation and owes to (i) the use ofthe independence approximation for the arrivalprocess of the second queue; (ii) the disregard ofthe ceiling function in the computation of thenumber of encryption blocks that correspond toone user packet of size Sd, and (iii) the disregardof the ceiling function in the computation of thespace overhead that is added to each protectedpacket.

7. Conclusions

This paper has presented an assessment of thecommunication overhead of IPsec and has evalu-ated the feasibility of deploying IPsec on handheldmobile devices and the UMTS radio interface pro-tocol architecture, which are characterized by lim-


ARTICLE IN PRESS

ited processing and bandwidth resources, respec-tively. In order to achieve these goals, we have firstquantified the processing overhead of IPsec in termsof the number of CPU cycles required forperforming security assuming the most prominentsecurity algorithms (i.e. DES, 3DES, AES, HMAC-MD5 and HMAC-SHA-1). Apart from the process-ing overhead, the application of IPsec adds anadditional space overhead by increasing the size ofthe final transmitted packets. The increase owes tothe extra security fields encapsulated with the userdata in the final packets, and has the natural effectof increasing both the packet transmission timeand the final output rate. We have quantified thespace overhead of IPsec, and we have given formu-las for expressing the size of the protected packets asa function of the size of the user data packets.

The analyzed overheads have been incorporatedin a simulation model that represents an IPsec-equipped UMTS mobile device. We simulatedfifty-three different security scenarios, and studiedthe performance in terms of throughput, packetdelay, and rate increase of the protected data fromthe application of IPsec. It has been observed thatthe more ‘‘lightweight’’ security schemes likeHMAC-MD5, HMAC-SHA-1, DES, and theAES encryption with a 128-bit key do not degradethe throughput of the system and that they hardlyhave an impact on the total delay, as long as theMS processing rate of 100 MIPS or greater. Onthe other hand, more complex security schemes like3DES and AES with a 192-bit or 256-bit key pro-vide for an increased resistance against attacks,but pose higher processing requirements and, thus,reduce the system throughput, when the MS pro-cessing rate is below 300 MIPS. Moreover, these

Appendix A

The following table presents the source data and the confor different data rates under an assumed processing rat(DES, DES + SHA-1, AES(128)Enc and AES(128)Enc +

Delay values

Rate No security DES DES + SHA

Low Mean High Low Mean High Low Me

144 57 59 61 75 78 81 77 8384 160 164 168 215 220 225 219 22512 232 240 248 311 318 325 317 32640 334 347 360 433 444 455 443 45768 504 519 534 638 653 668 653 66860 757 775 793 1022 1043 1064 1049 107900 938 957 976 1229 1254 1279 1259 128

algorithms have stronger impact on the total delayvalues and under sufficiently high user data rateslead to excessive delay values. Combining confiden-tiality with authentication services by addingHMAC-MD5 or HMAC-SHA-1 to AES, DESand 3DES increases even more the strain on theprocessor. This extra strain is, however, relativelysmall as compared to these imposed by the encryp-tion schemes.

The presented simulation results quantify the dif-ferences in communication overhead of the variousalgorithms and security options of IPsec, in the con-sidered resource constrained environment. Theseresults can be used for assisting IPsec adoption deci-sions, and in particular, the choice of a specific secu-rity scheme. Apart from the simulation model, wedeveloped a simple analytic model of an IPsec-equipped MS. This model, although approximate,captures the qualitative behavior of an actual sys-tem, and thus, can be used for quick investigationsof possible new IPsec deployment scenarios avoid-ing the need for laborious simulations.

As part of our on-going work we study IPsecperformance issues and their connection to usermobility and key exchange mechanisms.

Acknowledgement

Work supported in part by the project CASCA-DAS (IST-027807) funded by the FET Program ofthe European Commission and the Program‘‘PYTHAGORAS II: Support of Universities’ re-search groups’’ co-funded by the ‘‘Operational Pro-gramme for Education and Initial VocationalTraining’’ (O.P. ‘‘Education’’) and the EuropeanSocial Fund.

fidence intervals for Fig. 6. Delay values are derivede of 100 MIPS and different security configurations

SHA-1).

-1 AES(128)Enc AES(128)Enc + SHA-1

an High Low Mean High Low Mean High

0 83 81 83 85 82 84 864 229 224 228 232 228 232 2365 333 324 331 338 334 340 3466 469 457 467 477 471 482 4939 685 670 684 698 690 706 7221 1093 1076 1093 1110 1132 1152 11726 1313 1292 1312 1332 1345 1380 1415


ARTICLE IN PRESS

References

[1] K.H. Cheung, J. Misic, On virtual private networks securitydesign issues, Computer Networks 38 (2) (2002) 165–179.

[2] O. Elkeelany et al., Performance analysis of IPsec protocol:encryption and authentication, In: IEEE CommunicationsConference (ICC 2002), 2002, pp. 1164–1168.

[3] S. Miltchev, S. Ioannidis, A. Keromytis, A study of therelative costs of network security protocols, in: Proceedingsof USENIX 2002 Annual Technical Conference, Monterey,CA, June 2002.

[4] P. Ganesan et al., Analysing and modelling encryptionoverhead for sensor network nodes, in: Proceedings ofWSAN’03, San Diego, California, USA, September 2003.

[5] S. Kent, R. Atkinson, Security Architecture for the InternetProtocol, RFC 2401, November 1998.

[6] S. Kent, R. Atkinson, IP Authentication Header, RFC 2402,November 1998.

[7] S. Kent, R. Atkinson, IP Encapsulating Security Payload(ESP), RFC 2406, November 1998.

[8] W. Stallings, Network Security Essentials: Applications andStandards, Prentice-Hall, 2000.

[9] E. Danielyan, Goodbye DES, Welcome AES, Cisco TheInternet Protocol Journal 4 (2) (2001) 15–21.

[10] S. Frankel, R. Glenn, S. Kelly, The AES-CBC CipherAlgorithm and Its Use with IPsec, RFC 3602, September2003.

[11] R. Phan, Impossible differential cryptanalysis of 7-roundAdvanced Encryption Standard (AES), Information Pro-cessing Letters 91 (1) (2004) 33–38.

[12] D. Bertsekas, R. Gallager, Data Networks, Prentice-Hall,1992.

[13] US National Bureau of Standards, Data Encryption Stan-dard, Federal Information Processing Standard (FIPS)publication 46-2, December 1993. Available from: <http://www.itl.nist.gov/fipspubs/fip46-2.htm>.

[14] R. Rivest, The MD5 Message-Digest Algorithm, RFC1321,April 1992.

[15] D. Eastlake, P. Jones, US Secure Hash Algorithm 1 (SHA1),RFC 3174, September 2001.

[16] C. Madson, R. Glenn, The Use of HMAC-MD5-96 withinESP and AH, RFC 2403, November 1998.

[17] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 withinESP and AH, RFC 2404, November 1998.

[18] National Institute of Standards and Technology (NIST),Advanced Encryption Standard (AES), Federal InformationProcessing Standard (FIPS) publication 197, November2001. Available from: <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

[19] F. Granelli, G. Boato, A novel methodology for analysis ofthe computational complexity of block ciphers: Rijndael,Camellia and Shacal-2 compared, in: 3rd Conference onSecurity and Network Architectures (SAR’04), June 2004.Available from: <http://eprints.biblio.unitn.it/archive/00000514/01/DIT-04-004.pdf>.

[20] J. Daemen, V. Rijmen, The Design of Rijndael, Springer,2002.

[21] C. Lu, S. Tseng, Integrated Design of AES (AdvancedEncryption Standard) Encrypter and Decrypter, in: Pro-

ceedings of the IEEE International Conference on Applica-tion-Specific Systems, Architectures, and Processors(ASAP’02), 2002.

[22] ETSI, Universal Mobile Telecommunication System(UMTS); Selection Procedures for the Choice of RadioTransmission Technologies of the UMTS, Technical ReportTR 101 112 v3.2.0,1998.

[23] J. Korhonen, Introduction to 3G Mobile Communications,Artech House, 2003.

[24] 3GPP TS 25.321 (v3.15.0), Medium Access Control (MAC)protocol specification, release ’99, March 2003.

[25] 3GPP TS 25.322 (v3.6.0), Radio Link Control (RLC)protocol specification, release ’99, March 2001.

[26] 3GPP TS 25.323 (v3.4.0), Packet Data Convergence Protocol(PDCP) specification, release ’99, March 2001.

[27] ARM microprocessor solutions from ARM Ltd. Availablefrom: <http://www.arm.com/products/CPUs>.

Christos Xenakis ([email protected])received his B.Sc. degree in computerscience in 1993 and his M.Sc. degreein telecommunication and computernetworks in 1996, both from theDepartment of Informatics and Tele-communications, University of Athens,Greece. In 2004 he received his Ph.D.from the University of Athens (Depart-ment of Informatics and Telecommuni-cations). From 1998 to 2001 he was with

a Greek telecoms system development firm, where he wasinvolved in the design and development of advanced telecom-
munications subsystems for ISDN, ATM, GSM, and GPRS.Since 1996 he has been a member of the Communication Net-works Laboratory of the University of Athens. Currently, he is avisiting Lecturer in the Department of Informatics and Tele-communications, University of Athens. He has participated innumerous projects realized in the context of EU Programs(ACTS, ESPRIT, IST). His research interests are in the field ofmobile/wireless networks and security. He is the author of over20 papers in the above areas.
Nikos Laoutaris received the Ph.D.degree from the Department of Infor-matics and Telecommunications of theUniversity of Athens, Greece, in 2004,for his work in the area of ContentNetworking. He also holds an M.Sc.degree in Telecommunications andComputer Networks (2001) and a B.Sc.degree in Computer Science (1998), bothfrom the same department. His mainresearch interests are in the analysis of

algorithms and the performance evaluation of Internet contentdistribution systems (CDN, P2P, web caching) and multimedia
streaming applications. He is currently a Marie Curie OutgoingInternational post-doctoral fellow at the Computer ScienceDepartment of Boston University.
http://www.itl.nist.gov/fipspubs/fip46-2.htm

http://www.itl.nist.gov/fipspubs/fip46-2.htm

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

http://eprints.biblio.unitn.it/archive/00000514/01/DIT-04-004.pdf

http://eprints.biblio.unitn.it/archive/00000514/01/DIT-04-004.pdf

http://www.arm.com/products/CPUs


ARTICLE IN PRESS

Lazaros Merakos ([email protected])received the Diploma in electrical andmechanical engineering from theNational Technical University of Ath-ens, Greece, in 1978, and the M.S. andPh.D. degrees in electrical engineeringfrom the State University of New York,Buffalo, in 1981 and 1984, respectively.From 1983 to 1986, he was on the facultyof Electrical Engineering and ComputerScience at the University of Connecticut,

Storrs. From 1986 to 1994 he was on the faculty of the Electricaland Computer Engineering Department at Northeastern Uni-
versity, Boston, MA. During the period 1993–1994 he served asDirector of the Communications and Digital Processing ResearchCenter at Northeastern University. During the summers of 1990and 1991, he was a Visiting Scientist at the IBM T.J. WatsonResearch Center, Yorktown Heights, NY. In 1994, he joined thefaculty of the University of Athens, Athens, Greece, where he ispresently a Professor in the Department of Informatics andTelecommunications, and Director of the Communication Net-works Laboratory (UoA-CNL) and the Networks Operationsand Management Center. His research interests are in the designand performance analysis of broadband networks, and wireless/mobile communication systems and services. He has authoredmore than 150 papers in the above areas. Since 1995, he is leadingthe research activities of UoA-CNL in the area of mobile com-munications, in the framework of the Advanced CommunicationTechnologies & Services (ACTS) and Information SocietyTechnologies (IST) programmes funded by the European Union(projects RAINBOW, Magic WAND, WINE, MOBIVAS,POLOS, ANWIRE). He is chairman of the board of the GreekUniversities Network, the Greek Schools Network, and memberof the board of the Greek Research Network. In 1994, he receivedthe Guanella Award for the Best Paper presented at the Inter-national Zurich Seminar on Mobile Communications.
Ioannis Stavrakakis: Diploma in Electri-cal Engineering, Aristotelian Universityof Thessaloniki, (Greece), 1983; Ph.D. inEE, University of Virginia (USA), 1988;assist. Prof. in CSEE, University ofVermont (USA), 1988–1994; assoc. prof.of ECE, Northeastern University, Bos-ton (USA), 1994–1999; assoc. prof. ofInformatics and Telecommunications,University of Athens (Greece), 1999–2002 and prof. since 2002. Teaching and

research interests are focused on resource allocation protocolsand traffic management for communication networks, with recent
emphasis on peer to peer, wireless, sensor and ad hoc networking.His past research has been published in over 130 scientific jour-nals and conference proceedings and was funded by NSF,DARPA, GTE, BBN and Motorola (USA) as well as Greek andEuropean Union (IST) Funding agencies. He has served repeat-edly in NSF and IST research proposal review panels andinvolved in the organization of numerous conferences sponsoredby IEEE, ACM, ITC and IFIP societies. He is a senior member ofIEEE, a member of (and has served as an elected officer for) theIEEE Technical Committee on Computer Communications(TCCC) and the chairman of IFIP WG6.3. He has served as a co-organizer of the 1996 International Teletraffic Congress (ITC)Mini-Seminar, the organizer of the 1999 IFIP WG6.3 workshop,a technical program co-chair for the IFIP Networking’2000,EWC’04 and IFIP WiOpt’05 conferences, the Vice-General Chairfor Networking’2002 conference, the organizer of the COST-IST(EU)/NSF(USA)-sponsored NeXtworking’03 and theWorkshop on Autonomic Communications (WAC2005). He is anassociate editor for the IEEE/ACM transactions on Networking,the ACM/Baltzer Wireless Networks Journal and the ComputerNetworks Journals.

jurnal overhead ipsec 1

Documents