The role of Internet Protocol (IP) is becoming more and more problematic especially with the new requirements of mobility and multihoming. Host Identity protocol (HIP) defines a new protocol between the network and transport layers in order to provide a better management to those requirements. The protocol defines a new namespace based on cryptographic identifiers which enable the IP address roles dissociation. Those new identifiers identify hosts rather than IP addresses. Because HIP is a quite recent protocol, we propose to present an experimental evaluation of its basic characteristics.
The Internet user nowadays is no longer the same one as decades ago. Recent unprecedented growth of the mobile technology market, devices support for more than one of a myriad of technologies and operators, and the need to communicate from anywhere and at any time are the challenges of nowadays networks [
Few new Internet generation solutions were proposed last years as attempts to solve this problematic. However, their success was partial and limited for two reasons. First of all, those solutions can be described by “tiny” ones since they were too specialized. For instance, MobileIP (MIP) focuses mainly on mobility issues; IPsec is addressing only security issues, and so forth. All of them look to the problem from one side and none of them treated it as a whole one. Secondly, all the provided solutions were based on the traditional TCP/IP stack and tried just to adapt it [
Since the protocol is quite recent, going through its experimental evaluation seems to be interesting and very beneficial to give some conclusions about its performances. The idea of our study turns around that point. In fact, the present paper consists in an experimentation of HIP basic features. Different types of scenarios were performed in order to evaluate the basic characteristics of HIP. The goal of this research is to achieve providing some practical results about HIP.
The remainder of this paper is organized as follows. In Section
Currently, two namespaces are used in the Internet architecture: the Domain Name Service (DNS) names [
Identity and location roles separation.
Many efforts have been carried out in order to handle with this problematic. Therefore, many solutions have been proposed solving the problem from different points of view. Decoupling the location from the identity seems to be the most straightforward solution. This idea was discussed, few years ago, in the Internet Engineering Task Force (IETF) [
Comparison between current IP and HIP binding.
Having on the one hand a rich theoretical specification of the protocol, and on the other hand some practical obsolete results about HIP-based on old and expired drafts, this creates the need to investigate an experimental experience of the protocol referring to the last and the most updated HIP implementation. To do this, some tests scenarios were set up and measurements values were collected in order to be able to retrieve some useful conclusions about HIP.
We used the nightly tarball version of HIPL. This version is the most up-to-date one and contains the latest code developed. We installed HIP on two machines; one plays the initiator’s role and the other, the responder’s role. In fact, HIPL uses a modified version of Linux 2.6 Kernel. Therefore, to install HIPL on any machine, we need first to install the HIPL kernel provided for free download on the site of the project [
The target of this work is to test the performance of HIP on different networks and hosts types and the impact of introducing the new namespace especially in terms of delays comparing to the performances we dispose now.
Here, the different tests that can be performed in the context of this research are enumerated. Also, the utility of each proposed scenario will be explained.
The BE is the first phase of any HIP communication and it precedes any data exchange. The duration of this step is with relevant importance in evaluating the performance of HIP since it is a mandatory phase whenever two hosts want to communicate in a HIP way and affects roughly the rapidity of communications establishment.
The idea behind varying the technology or the hardware specifications is to see how much HIP behavior, more specifically the BE duration, is affected by the type of the link between the hosts as well as the type of the devices.
Among this test, we are going to measure five times
Times measured in A1, A2, and A3 subscenarios.
Tbe is the total time of the BE. We consider that this time is equal to the difference between two dates
Longer the BE is, longer the nodes have to wait to begin the effective data transmission and worst are the performances of the network. This is why it seems interesting to have an idea about the total time required to establish a HIP association and also how this time is distributed between the initiator and the responder. The same test is performed each time by varying a parameter: Network technology (Ethernet, Wifi), types of devices (powerful, lightweight). So we can distinguish 3 subscenarios as shown in Table
Subscenarios A1, A2, and A3 features.
Characteristics | Scenario name | ||
A1 | A2 | A3 | |
Initiator | Laptop | Laptop | Laptop |
Responder | PC | PC | Tablet |
Network technology | Ethernet | Wifi | Wifi |
Round Trip Time (RTT) is the time that a packet needs to travel from a source IP address to a destination IP address and come back. More exactly, the time that we measure here is equal to the time of sending an ICMP ECHO REQUEST packet, processing the packet and receiving its response, an ICMP ECHO RESPONSE. Scenario B is subclassified into three subscenarios: B1, B2 and B3 as shown in Table
Subscenarios B1, B2, and B3 features.
Characteristics | Scenario name | ||
B1 | B2 | B3 | |
Initiator | Laptop | Tablet | Laptop |
Responder | PC | Laptop | Tablet |
Network technology | Ethernet | Wifi | Wifi |
Since HIP uses encryption to process its data packets. Obviously, the RTT duration will be affected. Using this test, we try to highlight this by making a comparison between RTT with HIP and RTT without HIP.
The throughput can be defined as the average of useful data rate that are transmitted in a communication link. Usually it is measured relatively to a period of time. It depends on the protocols used, the introduced overhead and surely on the type of technology link in use. Since HIP introduces obviously some modifications to the structure of packets transmitted in the network and then surely to the amount of useful data transmitted. Having a look on how does HIP influence the throughput on a link is a relevant test. For this reason, the throughput in different types of communications was measured.
A TCP-based communication without HIP (TCP),
A UDP-based communication without HIP (UDP),
A TCP-based communication with HIP (TCP/HIP),
A UDP-based communication with HIP (UDP/HIP).
The scenario is also divided into two subscenarios: subscenario C1 where only Ethernet link is used and subscenario C2 where a wireless link is introduced as shown in Table
Subscenarios C1 and C2 features.
Characteristics | Scenario name | |
C1 | C2 | |
Initiator | Laptop | Laptop |
Responder | PC | PC |
Network technology | Ethernet | Wifi |
The test consists of sending a 100 Mb file of random data 10 times from the initiator to the responder and measuring each time the throughputs. The goal of the test is to make a comparison between throughputs with and without HIP and for both TCP and UDP connections.
Scenario A was performed in the purpose of measuring the total duration of the HIP Base Exchange as well as the time intervals spent both on the initiator and responder’s sides. Here, the different mean values obtained from the tests are depicted in Tables
Scenario A–BE time measurements (milliseconds).
Average | Sub scenario | Sub scenario | Sub scenario |
Time (milliseconds) | A1 | A2 | A3 |
17.037 | 16.648 | 14.419 | |
98.849 | 90.599 | 1073.322 | |
64.684 | 56.019 | 52.729 | |
6.016 | 5.878 | 256.823 | |
188.418 | 170.144 | 1409.971 |
Scenario A–BE time measurements (%)
% | Sub Scenario | Sub Scenario | Sub Scenario |
A1 | A2 | A3 | |
9.042% | 9.784% | 1.022% | |
52.462% | 53.248% | 76.109% | |
34.33% | 32.924% | 3.739% | |
3.192% | 3.454% | 18.214% |
Scenarios a results—BE time measurements (%).
Based on the measurements values, the following conclusions were made.
(i) With a fast look at the values obtained, it can easily notice the following. The BE duration in A3, when a tablet is involved, exceeds greatly the time obtained in the first two subscenarios. In addition, we remark that in the three experiences,
(ii) The average time elapsed to establish the HIP association using wired links is about 188.5 milliseconds. However, in the presence of a wireless link, it takes approximately 170 milliseconds, which means about 18 milliseconds less. The difference is considered as a small one. Thus, the introduction of a wireless link does not affect the protocol. The difference can be due to the use of different network cards and the number of hops in the test network.
(iii) Referring to the measurements values in A1 and A2, the responder takes 81.721 milliseconds (resp., 72.667 milliseconds) to process I1 packet, create R1, process I2 and create R2. However, an average of 104.865 milliseconds (resp., 96.477 milliseconds) is needed by the initiator to process R1, create I2, process R2 and create the first ESP packet. In terms of percentages, about 43% (resp., 42%) of the BE time is consumed by the responder and approximately 55% (resp., 56.702%) consumed by the initiator. This stands for the basic idea behind the Base Exchange in HIP, which is avoiding DoS attacks by making the initiation of the communication expensive to perform in terms of CPU cycles. The initiator has to spend much more time than the responder to establish the HIP association. However, the result is a bit surprising because the difference between the two percentages is a thin one, about 14% in both cases. This can be explained by the difference of computation capabilities between the two hosts. In fact, in our case, the initiator is more powerful than the responder in terms of hardware specifications. This is why it can process and create its packets relatively in a rapid way compared to the responder even though it has much more work to do. For instance, the same test being performed with two hosts having the same hardware specifications gives the following results: 75% of the time is consumed by the initiator, and only 25% by the responder.
Hence, the hardware characteristics of both used hosts for these experiments are highly influencing the distribution of BE time between the two parties even if the protocol was designed to engage the initiator more.
(iv) In all the subscenarios under run, we remark that
This result is expected, because this step includes solving the puzzle and generating the D-H keying material which is a bit demanding, especially if the puzzle difficulty is a high one.
In the two first subscenarios,
(v) The results of A1 and A2 are compared to A3’s ones. In fact, A1 and A2 were performed using the same types of devices, PC and laptop. How much does network technology affect on HIP? Using the third subscenario, it is shaded the light on HIP with lightweight devices which is an important point to study for any next generation protocol. In fact, the performance of the protocol when used with limited power environments, like tablets, is very important because such devices are the essential components of the future Internet. So the most relevant result to mention is that the laptop outperforms remarkably the tablet. In fact, the BE takes about 1.5s, which is about 7 times the duration calculated in the first subscenarios.
(vi)
Test scenario B was performed in order to measure the influence of the introduction of HIP on RTTs. It is interesting here too to measure the RTTs with Internet tablets and compare that to the results found with the laptop Table
Test Scenario B results-RTT measurements (milliseconds).
RTT (milliseconds) | Sub Scenario B1 | Sub Scenario B2 | Sub Scenario B3 |
---|---|---|---|
IPv6 | 0.430 | 1.242 | 1.867 |
HIP | 0.539 | 1.614 | 2.841 |
Test Scenario B results—RTT measurements (milliseconds).
(i) A fast look at the measurements obtained permits to affirm that HIP increases the RTTs values on the network. This can be explained by the ESP header added by HIP. In fact, having the packet encrypted requires more time at the hosts to decrypt and process them.
(ii) The first RTT measured in each scenario with HIP is the biggest one among all the other values obtained. This is understandable since during the first RTT, the two parties have to establish the HIP association to be able later to exchange the encrypted ICMP packets.
(iii) The RTT increases by 25% in a totally wired network, 30% in a network where a wireless link is introduced and 52% in the presence of an Internet tablet as a HIP host. Therefore, it can be concluded that HIP affects greatly the non powerful devices compared to other devices. However, normally the increase caused by HIP in C1 and C2 should be the same. A different result was found in these tests. Because the length of the packets after introducing HIP is the same in C1 and C2, this difference is caused by the access point and the time it requires to process the packets to the host.
(iv) RTT values are increased in the presence of a wireless link. This is due too to the presence of the access point too.
This scenario was run for the following purpose: measuring the impact of HIP on throughputs. The results obtained are collected in Table
Scenario C test results-throughputs (Mb/s).
Throughputs Mbits/s | Ethernet | Wireless |
---|---|---|
TCP | 8.773 | 4.443 |
TCP + HIP | 8.538 | 4.199 |
UDP | 9.419 | 5.295 |
UDP + HIP | 8.973 | 4.998 |
Test Scenario C results—Throughput (Mbits/s) for different protocols.
(i) The introduction of HIP decreases the throughput values in both TCP and UDP communications. This can be explained by the overhead introduced by HIP which corresponds to the ESP encryption.
(ii) UDP throughput decreases by about 5% in the case of wired and wireless networks. However, for TCP, the decrease is 2.75% in wired and about 5.8% in wireless. The reduction is bigger in the case of TCP because this latter sends acknowledgments whenever packets are lost. Also the difference of throughput between TCP and TCP with HIP is due to the ESP header added in addition to the acknowledgments packets sent.
(iii) An interesting point to mention is that HIP influences greatly the throughput on tablet. For instance, it turns from 3.012 Mb/s to 1.979 Mb/s, which corresponds to a decrease of about 50% of the later throughput. And it is almost the same thing in the case of UDP.
The experimental results about HIP gave the opportunity to make some conclusions related to the basic properties of this new protocol. After analyzing in depth the protocol specifications, the study was fixing the test scenarios to perform depending on the selected features to be studied. Some practical results about HIP basic properties were drawn. HIP seems to present an interesting solution and a promising feature in next generation networks. The strong point of the protocol resides in a high degree of security, eventhough it increases the time of the communication in the case of powerfull devices; it is still understandable and acceptable since the security is added
A final conclusion about HIP is early to be drawn now, the protocol developments are still ongoing works. However, the work and the results presented can help to evaluate partially the current development status of HIP and surely serve for future works intending to improve the protocol performance.