Virtual Private Networks (VPNs) use the Internet or other data network service as a backbone to provide a secure connection across a potentially hostile WAN. Such security guarantees provide the motivation for VPN deployment. This security does, however, come at a performance cost brought about by the increased processing overhead. This paper presents an investigation into these overheads. In particular, this investigation will consider different user resource availability in addition to router type and encryption algorithms

Davy, Stephen

Malone, Paul

Ronan, John

Ó Foghlú, Mícheál

Waterford Institute of Technology Repository

Performance Implications of IPSec Deployment

WIT Repository

Performance Implications of IPsec DeploymentJohn Ronan, Steven Davy, Paul Malone, Mı́chéal Ó FoghluTelecommunications Software & Systems Group (TSSG), Waterford Institute of Technology, Ireland.E-mail:jronan,sdavy,pmalone,mofoghlu@tssg.orgAbstractVirtual Private Networks (VPNs) use the Internet orother data network service as a backbone to provide a se-cure connection across a potentially hostile WAN. Such se-curity guarantees provide the motivation for VPN deploy-ment. This security does, however, come at a performancecost brought about by the increased processing overhead.This paper presents an investigation into these overheads.In particular, this investigation will consider different userresource availability in addition to router type and encryp-tion algorithms.1. IntroductionThis work comes from the simulation of several broadcategories of users. Researchers with high speed net-working capabilities (GEANT) and SMEs, with more con-strained bandwidth links have very different resource avail-ability and as such suffer from different consequences ofIPsec performance overhead. The results will indicate therealistic performance of IPsec under a range of conditions.These conditions will be representative of various softwareand hardware platforms commonly available, correspond-ing to different user categories.In total, five user categories are represented in terms ofbandwidth; specifically 100Mbps, 34Mbps, 4Mbps, 2Mbpsand 1Mbps links. These were tested using three differentrouters (AMD Opteron, Compaq DL380 G2 and PentiumIII 550 10/100 ports). Two algorithms are being used (AESfor encryption and MD5 for authentication) and tests arebeing done for both TCP and UDP transport protocols.This work has evolved from an investigation within theTORRENT IST project where there is a requirement to en-cipher a communications link between one server (LAP)and many clients. In time, this has led to an evaluation ofthe performance implications of using IPsec to achieve thisgoal. This, in turn, has brought about a more detailed in-vestigation as it became apparent that there were scalabilityissues involved.This work is partly funded by TORRENT1, an IST FP5project and by SEINIT2 an IST FP6 Integrated Project.The results of this work will feed into WP4 of the SEINITproject.2 IPsec Protocol SuiteIPsec is the security architecture for the Internet Proto-col (IP). This protocol is applicable to both IPv4 and IPv6.The architecture is defined in [1] and addresses the follow-ing 4 elements:• Security Protocols: Authentication Header (AH) [2]and Encapsulating Security Payload (ESP)[3].• Security Associations: Definition, management andprocessing.[6]• Key Management: The Internet Key Exchange (IKE)[6],[7],[8],[9].• Algorithms: Requirements of the authentication andencryption algorithms.2.1 Security ProtocolsTraffic Security is provided by two security protocols:• The Authentication Header protocol [2] provides con-nectionless integrity and data origin authentication.There is also an optional anti-replay service available.• The Encapsulating Security Payload protocol [3] [4][5] potentially provides two types of security service.The first is confidentiality via encryption and limitedtraffic flow confidentiality. The second type is con-nectionless integrity, data origin authentication and ananti-replay service.Either of these protocols can be applied alone or in com-bination, thus providing the desired level of security. TheIPsec security protocols are represented by headers that ap-pear before the IP header in the IP packet.1www.torrent-innovations.org2www.seinit.org1702.2 Security AssociationsThe security protocol headers do not contain informa-tion pertaining to the cryptographic algorithms and the as-sociated parameters. These representations are achievedthrough the transmission of aSecurity Parameter Index(SPI). This index combined with the destination IP ad-dresses and the type of protocol header (AH or ESP) de-termines the parameters of the IPsec processing.These parameters of a unidirectional security service arerepresented by a Security Association (SA). There are twotypes of SAs:• Transport Mode SA: This is a security association be-tween two hosts, generally used to secure the traffic ofthe upper layer protocols.• Tunnel Mode SA: This is a security association in anIP-in-IP tunnel, generally used in connecting to secu-rity gateways.2.3 Key ManagementIPsec mandates support for two separate methods ofcryptographic key and SA management: manual and au-tomatic.• Manual Key Management: This is the simplest formof key management and involves each IPsec connec-tion to be configured manually on both hosts. Whilethis is suitable in small static situations, it is unsuit-able in larger deployment scenarios due to scalabilityproblems.• Automatic Key and SA Management: Larger deploy-ment scenarios call for an Internet-standard, scalableand automated SA and key management protocol.This is provided byInternet Key Exchange (IKE). IKEis required to allow for use of anti-replay features ofAH and ESP and to facilitate on-demand creation ofSAs.2.4 AlgorithmsThe IPsec protocol suite does not define the authenti-cation and encryption algorithms used in implementations.These are defined in individual RFCs per algorithm. Algo-rithms used in these tests were:• AES [10]• HMAC-MD5 [11] [12]Our reasons for choosing these algorithms are higherperformance and are detailed in [?].3 ScenariosThe version of IPsec used for this paper is built into the2.6+ linux [14] kernels, for this paper the 2.6.1 kernel wasused. There are a number of tools [15] that come with thekernel to aid in setting up the security associations neededfor two hosts to speak IPsec, setkey command is used here.setkey can setup either tunnel or transport mode securityconnection.The scenario is as follows: a set of routers will routesecure traffic between two seperate networks, where thethird network is assumed untrusted and simulates the In-ternet. After this scenario is set up, the bandwidth on thelinks is shaped to replicate common configurations in realworld sceanrios. The configurations that are replicated rep-resent researchers with the high speed network capabilities(GEANT) and SME’s with more constrained bandwidthlinks. This translates into running the experiments over100Mbps,34 Mbps, 4Mbps, 2Mbps and 1Mbps networks.10.37.100.50Untrusted Network192.168.10.100192.168.10.2159.10.10.1159.10.10.210.37.100.40Secure VPNFigure 1. Illustration of Network Scenario4 Testbed ConfigurationThere are three networks in this experiment,192.168.10.0 is the Server network, 10.37.100.0 isthe Client network and 159.10.10.0 is the assumed un-trusted network. The Server is located at 192.168.10.100,and the Client is located at 10.37.100.40. The routerswill be set up to route traffic from Server to Client andthe return path. Note though that IP forwarding must firstbe enabled with the following command on both routersbefore traffic can be routed. After this is set up, any packetrecieved by the router, that is not destined for one ofits interface addresses, is routed through the appropriateinterface. This interface is determined from the routes setup on the router.echo 1 > /proc/sys/net/ipv4/ip_forwardingIPS 2004 Budapest, Hungary1714.1 Equipment usedAll of the machines involved were using Linux Kernelversion 2.6.1• SERVER = Dual PIII 850 blade server running100Mbps• CLIENT = Dual PIII 850 blade client running100Mbps• ROUTER1 = Dual Xeon 2.4Ghz Compaq DL380-G3• ROUTER2 = Dual PIII 850• ROUTER3 = Dual AMD Opteron 24004.2 Setting up the routesThe Server machine needs to know how to route trafficto the Client network, located in the 10.37.100.0 network.This traffic is routed to the Server Router.route add -net 10.37.100.0 \netmask 255.255.255.0 gw 192.168.10.2The Client machine needs to know how to route trafficto the Server network, located in the 192.168.10.0 network.This traffic is routed to the Client Router.route add -net 192.168.10.0 \netmask 255.255.255.0 gw 10.37.100.50The Server router can route traffic directly to the Clientrouter, so any traffic this router recieves destined for theClient network is sent to the Client routerroute add -net 10.37.100.0 \netmask 255.255.255.0 gw 159.10.10.2The Client router can route traffic directly to the Serverrouter, so any traffic this router recieves destined for theServer network is sent to the Server router.route add -net 192.168.10.0 \netmask 255.255.255.0 gw 159.10.10.14.3 Setting up IPsec Tunnel modeWe used manual keying for both authentication and en-cryption. As we wished to measure the performance ofthe routers. Tunnel Mode was employed. The securityassociation provides confidentiality, data origin authentica-tion, and connectionless integrity through the use of ESP.The crytographic algorithm used for ESP confidentiality isAES, and for ESP authentication is MD5. The following isapplied to the setkey command (through the -f option) onthe Router on the Client Side.spdflush;flush;add 159.10.10.2 159.10.10.1 \esp 0x750 -m tunnel -E rijndael-cbc \0x11112222333344445555666677778888 \-A hmac-md5 \0x11112222333344445555666677778888;add 159.10.10.1 159.10.10.2 \esp 0x850 -m tunnel -E rijndael-cbc \0x11112222333344445555666677778888 \-A hmac-md5 \0x11112222333344445555666677778888;spdadd 192.168.10.100/32 10.37.100.40/32 \any -P out IPsec \esp/tunnel/159.10.10.2-159.10.10.1/require;spdadd 10.37.100.40/32 192.168.10.100/32 \any -P in IPsec \esp/tunnel/159.10.10.1-159.10.10.2/require;And the router on the Server sidespdflush;flush;add 159.10.10.2 159.10.10.1 \esp 0x750 -m tunnel -E rijndael-cbc \0x11112222333344445555666677778888-A hmac-md5 \0x11112222333344445555666677778888;add 159.10.10.1 159.10.10.2 \esp 0x850 -m tunnel -E rijndael-cbc \0x11112222333344445555666677778888-A hmac-md5 \0x11112222333344445555666677778888;spdadd 192.168.10.100/32 10.37.100.40/32 \any -P in IPsec \esp/tunnel/159.10.10.2-159.10.10.1/require;spdadd 10.37.100.40/32 192.168.10.100/32 \any -P out IPsec \esp/tunnel/159.10.10.1-159.10.10.2/require;Spdflush and flush erase all IPsec associations in thekernel then, the one that are used for the experiments areadded. An association is set up on theclient router to theserver router and vice-versa In summary, the above com-mands tell the kernel to apply ESP tunnel mode IPsec topackets originating from address 192.168.10.100 (Server)and with destination address 10.37.100.40 (Client). An as-sociation in the kernel is created for the opposite directionalso.Performance Implications of IPSec Deployment1724.4 Performance Measuring SetupThe main performance measure this paper is focused onis the throughput, and processor overhead associated withIPsec. The throughput was measured with Iperf. Iperf[16] is a freely available, multi-platform bandwidth mea-surement tool. Iperf can measure many network relatedparameters, in this case we were really only interested inbandwidth, the processor overhead generated on the routerand the relationship between them. As we wished to mea-sure lower bandwidths than 100Mbps, the linux traffic con-troller tc was used to achieve lower throughputs.4.4.1 Setting up tctc is a linux program used to control and shape traffic on aninterface, although this program has quite a complex set ofoptions, only one was used for our purposes.tc qdisc add dev eth0 root tbf rate 34mbit \burst 10kb latency 70msThe above command will constrain the related networkinterface to a throughput of 34 Mbps. A command similiarto this was issued on both routers before Iperf was started.4.4.2 Setting up cyclesoakCyclesoak [17] is a tool for accurately measuring systemload andused to measure CPU utilization, by soaking up allidle cycles and calculating the load on the CPU. This toolis run on both routers, as it was here that we were interestedin the processor overhead.4.5 Performance TestsThere were three routers in all, each with dual process-ing cababilites. Tests were performed on the routers insingle processor mode and dual processor mode, to givea richer set of results.5. ResultsIf we first examine Figure 3, we can see that all therouters are capable of routing 34Mbps of IPsec encryptedtraffic with varying loads on the processors (Figure 5,colums labeled 34, 4, 2, 1). This is also reflected in Ta-bles 1, 2 and 3.Interestingly, as can be seen from Figure 5, one coulddeploy a Single Processor Pentium III machine to act as aVPN gateway if the bandwidth requirements were 34Mbps(Figure 5) or less, with some headroom. Whats is also in-teresting is the comparison of the Xeon versus the OpteronRouters. The addition of the second processor has a far 0 20 40 60 80 10010034 4 2 1OverheadAMD - MultiAMD - SingleXEON - MultiXEON - SinglePIII - MultiPIII - SingleFigure 2. Overhead Analysis 0 20 40 60 80 10010034 4 2 1Throughput in MbpsAMD - MultiAMD - SingleXEON - MultiXEON - SinglePIII - MultiPIII - SingleFigure 3. Throughput AnalysisTable 1. Flextel Blade Dual PIII 850 MhzLink Speed Router Single Router DualThroughput Overhead Throughput Overhead100 61.1 100% 70 70.9%34 32.5 50.6% 31.8 32.5%4 3.8 8.6% 3.8 4.1%2 1.92 4.8% 1.92 2.3%1 960 2.8% 960 1.5%Table 2. Dual Xeon 2.4GhzLink Speed Router Single Router DualThroughput Overhead Throughput Overhead100 93.8 73.98% 93.8 23.21%34 32.5 32.9% 32.5 9.28%4 3.8 9.56% 3.8 3.12%2 1.92 6.01% 1.92 2.01%1 960 4.23% 960 .71%IPS 2004 Budapest, Hungary173Table 3. AMD Dual Opteron 2400Bandwidth Router Single Router DualThroughput Overhead Throughput Overhead100 93.8 52.03% 93.8 30.13%34 32.7 17.96% 32.7 10.38%4 3.8 2.4% 3.8 1.38%2 1.92 1.25% 1.92 .66%1 .96 .6% .96 .31%greater effect than one would expect with the addition ofa single processor. It manifests itself as the single proces-sor Opteron showing less overhead than the Single proces-sor Xeon, and the Dual Opteron showing more overheadthan the Dual Xeon. This appears to be the effect the XeonHyper-Threading Technology has; we need to investigatethis further.6. Conclusion & Further WorkWe need to return to the issue of the Xeon’s Hyper-Threading technology. Also we would like to comparethese results against a commercial offering. Also we wouldlike to investigate how the addition of Hardware Acceler-ators would aid asoftware router to compete against thecommercial offering.References[1] S. Kent, R. Atkinson, Security Architecture for the InternetProtocol. RFC 2401, November 1998.[2] S. Kent, R. Atkinson,IP Authentication Header. RFC 2402November 1998.[3] S. Kent, R. Atkinson, IP Encapsulating Security Payload.RFC 2406, November 1998.[4] R. Pereira, R. Adams, The ESP CBC-Mode Cipher Algo-rithms. RFC 2451, November 1998.[5] S. Frankel, R. Glenn, and S. Kelly The ESP CBC-Mode Ci-pher Algorithms. RFC 3602, September 2003.[6] D. Maughan, M. Schertler, M. Schneider, and J. TurnerIn-ternet Security Association and Key Management Protocol.RFC 2408, November 1998.[7] H. Orman,The OAKLEY Key Determination Protocol. RFC2412, November 1998.[8] D. Piper, The Internet IP Security Domain of Interpretationfor ISAKMP. RFC 2407, November 1998.[9] D. Harkins, D. CarrelThe Internet Key Exchange (IKE) RFC2409, November 1998.[10] S. Franker, S. Kelly, and R. GlennThe AES Cipher Algo-rithm and Its Use with IPsec RFC 3602, September 2003.[11] C. Madson, R. Glenn, The Use of HMAC-MD5-96 withinESP and AH. RFC 2403, November 1998.[12] H. Krawczyk, M. Bellare, and R. Canetti.HMAC: Keyed-Hashing for Message Authentication. RFC 2104 February1997.[13] J. Ronan, P. Malone, and M.́O Foghlu Overhead Issuesfor Local Access Points in IPsec enabled VPNs.Interdo-main Performance and Simulation Workshop, Salzburg Aus-tria, February 2003.[14] Linux http://www.linux.org Last Accessed, March7th 2004.[15] IPsec-Tools http://ipsec-toolos.sourceforge.net Last Ac-cessed, March7th 2004.[16] Iperf http://dast.nlanr.net/Projects/Iperf Last Accessed,March7th 2004.[17] Cyclesoak http://www.zipworld.com.au/ akpm/linux/#zcLast Accessed, March7th 2004.Performance Implications of IPSec Deployment174

http://repository.wit.ie/648/1/2004_IPS_Ronan_et_al_final.pdf

Performance Implications of IPSec Deployment

Abstract

Similar works

Full text

Available Versions

Waterford Institute of Technology Repository

WIT Repository