Impact of IPSec Overhead on Web Application Servers
01 Dec 2006-pp 652-657
TL;DR: From the characterized metrics and computed overheads, the impact of IPSec on connection handling capacity of web application servers is analyzed by considering the user behaviour on web page requests.
Abstract: IPSec provides security solutions to various network based web applications through its protocol suite. Implementing IPSec in the network layer includes significant bandwidth and processing time overhead to application traffic. The upper layer protocols such as TCP and UDP behavior on network traffic is also influenced by these overheads. In our work, we have studied the impact of IPSec on the metrics: Number of Transactions, Transmission Time, Round Trip Time, Average Burst Size and Available Bandwidth for IPv4 and IPv6 network traffic. Authentication algorithm: Hashed Message Authentication Code - Message Digest 5(HMAC-MD5), encryption algorithm: Advanced Encryption Standard(AES) and compression algorithm deflate are considered for Authentication Header(AH), Encapsulated Security Payload(ESP) and IP Compression(IPComp) protocols of IPSec. Using the characterized metrics, computed overheads and user behavior on web page requests, we have analyzed the performance impact of IPSec on web application servers.
Citations
More filters
Journal Article•
TL;DR: Internet Key Exchange (IKE), resolves problems of building and updating key that is shared in the unsafe environment such as Internet.
Abstract: With the expeditious development of Internet, the security of communication is one of the most essential elements.Internet Key Exchange(IKE), resolves problems of building and updating key that is shared in the unsafe environment such as Internet.
60 citations
09 Nov 2008
TL;DR: This paper analyzes the use of statistical noise for the construction of proper DNS queries and aims at reducing the risk that sensible data within DNS queries could be inferred by local and remote DNS servers.
Abstract: The use of the DNS as the underlying technology of new resolution name services can lead to privacy violations. The exchange of data between servers and clients flows without protection. Such an information can be captured by service providers and eventually sold with malicious purposes (i.e., spamming, phishing, etc.). A motivating example is the use of DNS on VoIP services for the translation of traditional telephone numbers into Internet URLs. We analyze in this paper the use of statistical noise for the construction of proper DNS queries. Our objective aims at reducing the risk that sensible data within DNS queries could be inferred by local and remote DNS servers. We evaluate the implementation of a proof-of-concept of our approach. We study the benefits and limitations of our proposal. A first limitation is the possibility of attacks against the integrity and authenticity of our queries by means of, for instance, man-in-the-middle or replay attacks. However, this limitation can be successfully solved combining our proposal together with the use of the DNSSEC (DNS Security extensions). We evaluate the impact of including this complementary countermeasure.
18 citations
Proceedings Article•
23 Jun 2010TL;DR: Proxychain is presented - a novel VoIP authentication protocol based on a modified hash chain construction that improves performance and scalability, but also offers additional security properties such as mutual authentication.
Abstract: Authentication is an important mechanism for the reliable operation of any Voice over IP (VoIP) infrastructure. Digest authentication has become the most widely adopted VoIP authentication protocol due to its simple properties. However, even this lightweight protocol can have a significant impact on the performance and scalability of a VoIP infrastructure. In this paper, we present Proxychain - a novel VoIP authentication protocol based on a modified hash chain construction. Proxychain not only improves performance and scalability, but also offers additional security properties such as mutual authentication. Through experimental analysis we demonstrate an improvement of greater than 1700% of the maximum call throughput possible with Digest authentication in the same architecture. We show that the more efficient authentication mechanisms of Proxychain can be used to improve the overall security of a carrier-scale VoIP network.
17 citations
Proceedings Article•
08 Jun 2009TL;DR: VoIP quality due to using IPSec with IPv6, 6to4, and NAT in VPNs during the IPv4/IPv6 transition is not significantly different from using IPsec with IPv4,, and that there is a minimal impact on voice quality as long as the network capacity is not exceeded.
Abstract: We conduct experiments in a LAN environment to determine the impact of IPsec and 6to4 encapsulation on VoIP quality in future IPv6 networks. We measure VoIP performance in the presence of varying background traffic for each of four IPsec scenarios with IPv6 and 6to4 encapsulation, with and without NAT, and compare with IPv4. The scenarios reflect situations commonly encountered in today's VPNs including no-security (i.e., traffic bypasses IPsec), network-to-network (i.e., an IPsec VPN between corporate sites), client-to-network (i.e., remote user access to a corporate network via IPsec tunnels), and client-to-client (i.e., IPsec transport mode for secure end-to-end communication). We use the popular Openswan implementation of IPsec and focus on ESP with the authentication option. The measures used for evaluating VoIP performance are delta (packet inter-arrival time), jitter, packet loss, throughput, and MOS. Our results demonstrate that VoIP quality due to using IPsec with IPv6, 6to4, and NAT in VPNs during the IPv4/IPv6 transition is not significantly different from using IPsec with IPv4, and that there is a minimal impact on voice quality as long as the network capacity is not exceeded.
12 citations
Cites background from "Impact of IPSec Overhead on Web App..."
...For the networkto-network scenario, there is more variability in the delta values: at 0 and 50 Mbps, the standard deviation is 8 ms with either IP version or 6to4 encapsulation; at 100 Mbps it is 11 ms with IPv4 and IPv6, and 24 ms with 6to4; at 150 Mbps it is 21 ms with IPv6 and 6to 4 and 29 ms with IPv4; and at 200 Mbps it is 30 ms for 6to4 and approximately 40 ms for IPv4 and IPv6....
[...]
...Studies have also examined the IPsec overhead with IPv4 for email and Web applications [9], and Web servers with IPv4 and IPv6 [10]....
[...]
...For the no-security, client-to-client and client-to-network scenarios, there is very little difference in mean delta values with either IP version or 6to4 encapsulation, and it varies from 19-26 ms (the mean is 26 ms at 200 Mbps for no-security with IPv6 and 6to4, and for client-to-net with IPv4 and IPv6)....
[...]
...Their study compared the end-to-end throughput for IPv4 and IPv6 without IPsec, with only AH, with only ESP, and with both AH and ESP....
[...]
TL;DR: This study proposed a new spoofing defense mechanism based on IPsec’s protocol Encapsulated Security Payload (ESP), which proved that proposed mechanism has managed to eliminate spoofing threat in IPv6 over IPv4 tunnel.
Abstract: A considerable amount of time will be needed before each system in the Internet can convert from Internet Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6). Three strategies have been proposed by the Internet Engineer Task Force (IETF) to help the transition from IPv4 to IPv6 which are dual stack, header translation and tunneling. Tunneling is used when two computers using IPv6 want to communicate with each other and the packet will travel through a region that uses IPv4. To pass through this region, IPv6 packet must be encapsulated in IPv4 packet to have an IPv4 address in order to make it IPv4 routing compatible. Internet Protocol security (IPsec) in transport mode carries the payload of the encapsulating packet as a plain data without any mean of protection. That is, two nodes using IPsec in transport mode to secure the tunnel can spoof the inner payload; the packet will be de-capsulated successfully and accepted. IETF mentioned this problem in many RFCs. According to RFC 3964 there is no simple way to prevent spoofing attack in IPv6 over IPv4 tunnel and longer term solutions would have to be deployed in both IPv4 and IPv6 networks to help identify the source of the attack, a total prevention is likely impossible. This study proposed a new spoofing defense mechanism based on IPsec’s protocol Encapsulated Security Payload (ESP). ESP’s padding area had been used to write the IPv6 source address of the encapsulated packet. Simulation is conducted based on two scenarios, one with spoofing attack and one without. The outcome proved that proposed mechanism has managed to eliminate spoofing threat in IPv6 over IPv4 tunnel.
6 citations
References
More filters
01 Aug 1995
TL;DR: This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer, and obsoletes RFC 2401 (November 1998).
Abstract: This document describes an updated version of the "Security
Architecture for IP", which is designed to provide security services
for traffic at the IP layer. This document obsoletes RFC 2401
(November 1998). [STANDARDS-TRACK]
3,455 citations
01 Jun 1998
TL;DR: This paper applies a number of observations of Web server usage to create a realistic Web workload generation tool which mimics a set of real users accessing a server and addresses the technical challenges to satisfying this large set of simultaneous constraints on the properties of the reference stream.
Abstract: One role for workload generation is as a means for understanding how servers and networks respond to variation in load. This enables management and capacity planning based on current and projected usage. This paper applies a number of observations of Web server usage to create a realistic Web workload generation tool which mimics a set of real users accessing a server. The tool, called Surge (Scalable URL Reference Generator) generates references matching empirical measurements of 1) server file size distribution; 2) request size distribution; 3) relative file popularity; 4) embedded file references; 5) temporal locality of reference; and 6) idle periods of individual users. This paper reviews the essential elements required in the generation of a representative Web workload. It also addresses the technical challenges to satisfying this large set of simultaneous constraints on the properties of the reference stream, the solutions we adopted, and their associated accuracy. Finally, we present evidence that Surge exercises servers in a manner significantly different from other Web server benchmarks.
1,549 citations
TL;DR: This work describes an end-to-end methodology, called self-loading periodic streams (SLoPS), for measuring avail-bw, and uses pathload, a nonintrusive tool, to evaluate the variability ("dynamics") of the avail- bw in Internet paths.
Abstract: The available bandwidth (avail-bw) in a network path is of major importance in congestion control, streaming applications, quality-of-service verification, server selection, and overlay networks. We describe an end-to-end methodology, called self-loading periodic streams (SLoPS), for measuring avail-bw. The basic idea in SLoPS is that the one-way delays of a periodic packet stream show an increasing trend when the stream's rate is higher than the avail-bw. We have implemented SLoPS in a tool called pathload. The accuracy of the tool has been evaluated with both simulations and experiments over real-world Internet paths. Pathload is nonintrusive, meaning that it does not cause significant increases in the network utilization, delays, or losses. We used pathload to evaluate the variability ("dynamics") of the avail-bw in Internet paths. The avail-bw becomes significantly more variable in heavily utilized paths, as well as in paths with limited capacity (probably due to a lower degree of statistical multiplexing). We finally examine the relation between avail-bw and TCP throughput. A persistent TCP connection can be used to measure roughly the avail-bw in a path, but TCP saturates the path and increases significantly the path delays and jitter.
765 citations
07 Aug 2002
TL;DR: HMAC-MD5 can be sufficient for the authentication purposes rather than using the more complicated HMAC-SHA1 algorithm in encryption applications, and comparisons between these algorithms in terms of time complexity and space complexity.
Abstract: IPSec provides two types of security algorithms, symmetric encryption algorithms (e.g. data encryption standard DES) for encryption, and one-way hash functions (e.g., message digest MD5 and secured hash algorithm SHA1) for authentication. This paper presents performance analysis and comparisons between these algorithms in terms of time complexity and space complexity. Parameters considered are processing power and input size. The analysis results revealed that HMAC-MD5 can be sufficient for the authentication purposes rather than using the more complicated HMAC-SHA1 algorithm. In encryption applications, authentication should be combined with DES.
113 citations
Journal Article•
TL;DR: Internet Key Exchange (IKE), resolves problems of building and updating key that is shared in the unsafe environment such as Internet.
Abstract: With the expeditious development of Internet, the security of communication is one of the most essential elements.Internet Key Exchange(IKE), resolves problems of building and updating key that is shared in the unsafe environment such as Internet.
60 citations