From ICT-OPTIMIX website
Jump to: navigation, search

Bme small.jpg Hit small.jpg Mik small.jpg Optimix small.png

Host Identity Protocol (HIP) Simulation Framework for INET/OMNeT++

Hipsim 12B.jpg

We are proud to introduce HIPSim++ which is a Host Identity Protocol (HIP) Simulation Framework for INET/OMNeT++ developed to provide a flexible toolset for testing and validation of HIP and its extensions. HIPSim++ is fully OMNeT++ 4.x compatible as it is built on the top of the 20090325 version of INET , and also uses the xMIPv6 additions created by Dortmund University of Technology. Our HIP simulation model has been implemented with conformance to the IETF’s HIP specifications , and has been validated against a real-life HIP testbed applying the InfraHIP implementation. However our analysis show excellent accuracy and consistent operation of the simulation compared to the real-life experiences, it has to be noticed that HIPSim++ is an ongoing work, therefore refinements and further developments are continuously expected. To eliminate all the bugs we strongly encourage You to provide us feedbacks, hints, remarks, etc. by sending us e-mails . We will do our best to continuously enhance the code and also this webpage in the future. We hope that our model will find interest among the research community and can make a remarkable impact as the reference HIP simulation model in the INET/OMNeT++ world.

Download HIPSim++

Introduction: What is this HIP thing?

In the current Internet architecture, nodes are identified by IP addresses depending on the actual topological position of the nodes. Therefore IP addresses are simultaneously describing both the location in the network (Locator function) and the identity of a particular node (Identifier function). This semantically overloaded nature of IP addresses causes problems. The most prominent among them is mobility management: when the node changes its attachment point to the network (and thus its IP address), active sessions (which are mostly connected to the TCP/IP numbers) are interrupted. Obviously users want seamless handovers with continuous connections and sessions, so engineers must find an answer here. One of the promising solutions is called Host Identity Protocol (HIP). HIP introduces a new layer between the network layer (IP) and the transport layer. The new HIP layer uses dedicated, cryptographic identifiers (called Host Identity), which represents the identifier role in the sessions: transport protocols rely on these HIs, not the IP addresses. Thus, IP addresses remain only geographical locators; they purely identify the location of the nodes and no longer take care of the identification. With HIP, mobility and even multihoming is not a problem any more: nodes can simply change their IP addresses without loosing active connections. The authors of this simulation framework believe that based on the above mentioned paradigm and capabilities HIP can be applied for a plenty of interesting purposes and it can provide nice solutions in different areas. This is the reason why the development of a complete Host Identity Protocol simulator framework and the extensive validation of the developed protocol and its existing and emerging extensions are needed.

HIP in a nutshell

As mentioned in the introduction, HIP aims to separate the different roles of IP addresses. While IP continues to act as pure locator, HIP introduces a new, globally unique namespace (the Host Identity namespace), which is a pool of identity representations called Host Identifiers (HIs). These namespace elements are of cryptographic names used to identify nodes. Every HIP node has at least one HI and implements the functions required to handle the new namespace. The scope of the protocol includes the modifications and new methods that integrate the concepts of HIP into the existing Internet architecture. These functions form a new protocol layer, which resides between the transport and network layer. HIP separates application and transport layer connections from IP addresses thus enabling effective application of communication security techniques and mobility management [RFC 4423 ]. HIs could be of any globally unique namespace but during the protocol design they were decided to be cryptographic names, namely asymmetric key pairs. This enables the integration of strong security features such as authentication, confidentiality, integrity and protection against certain kind of Denial-of-Service (DoS) and Man-in-the-Middle (MitM) attacks and some other security threats. However, HIs are rarely used in HIP protocol packets. Instead a 128 bit long representation called the Host Identity Tag (HIT) is applied in HIP control messages. The HIT is created by taking a one-way hash on the HI. For local means and to enable IPv4 compatibility it is necessary to also have 32 bit representations of His; these are the Local Scope Identifiers (LSI). HIP related information is passed by HIP headers, which have a form of a standard IPv6 extension header. A HIP association can be established between two nodes (i.e. an Initiator and a Responder) by a four way end-to-end security handshake called the Base Exchange (BE) (see Figure 1).


Figure 1. The HIP Base Exchange

The BE authenticates the peers by asymmetric keys and implements a Diffie-Hellman key exchange to create symmetric keys for later payload encryption. Moreover, a special puzzle-solution mechanism is applied to protect the responder against certain DoS attacks. As a result of a successful HIP Base Exchange an IPSec Security Association pair is created between the peers. After the BE payload data is passed between the peers using the Encapsulating Security Payload (ESP). Note that HIP related info (i.e. the HIP header) is only applied to HIP control packets but not in case of data transfer messages. The inside protocol behavior is based on the protocol’s state machine [RFC 5201 ], which controls a HIP association during its lifetime. Using HIP mechanisms, the application data is transferred between the nodes through a special IPSec ESP tunnel. A new transport mode of ESP was designed especially for HIP [RFC 5202 ]. This so called Bound-End-to-End-Tunnel (BEET) mode integrates the ESP tunnel mode with the low overhead transport mode. Using BEET mode the outer IP header of the ESP packet holds the IP addresses of the peers but the inner header is missing. Instead the Security Parameter Index (SPI) is used to identify the correspondent HIP association by reception at the destination. A HIP association can be refreshed applying the UPDATE mechanism of the protocol (Figure 2) [RFC 5206 ]. The mobile simply sends an UPDATE HIP control packet to all of its peers with a special parameter, the LOCATOR that holds the new IP address(es).


Figure 2. The HIP UPDATE mechanism

Before updating its association, the peer verifies the new address by sending an UPDATE packet to the mobile node, which requests it to echo back some nonce information. An address becomes verified if this nonce was echoed back from that address. A HIP node can communicate with unverified addresses too but only for a limited time controlled by the Credit-Based Authorization (CBA) mechanism. The initial reachability of HIP mobile nodes is not solved by the basic readressing functionality of HIP. Thus the basic protocol was extended by a new registration mechanism [RFC 5203 ] and the HIP rendezvous service [RFC 5204 ]. Special HIP nodes, called Renezvous Servers (RVSs), offer their features for mobile nodes to store their actual HIT-IP mappings and to make them available to potential communication partners. Mobile nodes register and update their IP address at RVSs with the registration mechanism and store the IP address of the RVS in DNS system [RFC 5205 ]. If a peer wants to establish a HIP association with the mobile, it learns the actual RVS IP address with a DNS query and sends the first packet of the BE to the RVS. The server relays the packet to the actual IP address of the mobile node. The rest of the connection build up goes like usual. Figure 3 shows the registration and the RVS mechanisms.

Rvs small.png

Figure 3. The HIP registration and RVS extension

HIPSim++ basics

The main goal of HIPSim++ is to provide an extensible and precise simulation model for the emerging Host Identity Protocol. Considering that the 32bit LSIs are designed for local communication only (i.e. the benefits of the HIP scheme can’t be exploited totally on IPv4), HIPSim++ uses the IPv6 networking stack of INET such fulfilling the requirements of global HIP communication based on the 128bit HITs. Transparency of the novel HIP layer is another important requirement which should be guaranteed for practical reasons, but current HIP RFCs define only a few guidelines to support the transparent behavior of HIP in the current networking architecture. These guidelines were also followed during our development work. Despite the fact that HIP relies on the functions of IPSec, a full implementation of IPSec and relating algorithms is not part of our simulation model: HIPSim++ does not possess properly realized Diffie–Hellman mechanisms, RSA engine, cryptographic hash functions and puzzles because precise mapping of all the security algorithms is out of scope of our current efforts. The main design goal of HIPSim++ was to accurately simulate core HIP instruments focusing on the advanced mobility and multihoming capabilities and wireless behaviour of the protocol and providing only skeleton implementation of the above mentioned mathematical apparatus. The simplest scenario of introducing HIP into the ISO-OSI architecture is when applications continue to use IP addresses, and HITs (or LSIs) only appear in the newly introduced HIP layer. Besides the integration of the Host Identity Layer, no other modifications are to be applied in the current protocol stack if such a scenario is implemented. However this is an easy way to introduce basic HIP functions, it also restricts HIP’s general benefits of mobility and multihoming support. Therefore our implemented HIP layer registers HIT-IP bonds for every communication session, and when packets from the transport layer arrive, destination and source HITs are replaced by destination and source IP addresses. Higher layers know only about HITs and Port numbers: they are using HITs instead of IP addresses. By realizing this scenario, all the advantages and benefits of applying HIP can be exploited and also HIPSim++ can be easily used in the existing INET-based simulation models. In order to assess our model and to evaluate the accuracy and preciseness of the implementation, we built and configured a real-life HIP testing environment based on InfraHIP , and compared the outcomes of our simulation with the reference results obtained from the testbed. Our analysis show apparent accuracy and consistent operation of HIPSim++ in terms of handover metrics (latency, packet loss, throughput) and behavior when compared to the experiences gathered in the real-life HIP testbed. This accuracy has been provided by modeling HIP messages, nodes and mechanisms based on the actual recommendations of current IETF RFCs, and by re-using the existing detailed IPv6, mobility, channel, etc. models of INET/OMNeT++. For further details regarding our evaluation efforts and research activities please jump to the Publications section.

Modifications to INET

In order to implement HIP protocol mechanisms and to integrate HIPSim++ with the INET framework, several extensions and modifications have had to be introduced in the existing modules/classes of INET. However these modifications are not transparent to the INET building blocks, it has to be emphasized that the revision we made is basically a set of additional supplements, bugfixes and extensions without breaking or changing the original functionality. Here we are not intended to present all the details of the corresponding modifications but to give a list with a short overview about the changes and their nature.

  • /networklayer/IPv6/IPv6ExtensionHeaders.msg: insertion of HIP header and parameter structure; ESP header extended with SPI.
  • /networklayer/IPv6/ integration of mechanisms for HIP header management.
  • /Transport/UDP/ correction of a bug preventing proper UDP communication over IPv6/HIP.
  • /networklayer/IPv6/ correction of a bug causing memory leaks during packet transmission towards upper layers.
  • /networklayer/ICMPv6/ introduction a new NotificationBoard message designed to inform the HIP layer about address changes after finishing Duplicate Address Detection procedures of IPv6.
  • /linklayer/Ieee80211/mac/ introduction of a simple Radio module identifier for NotificationBoard messages.
  • /linklayer/Ieee80211/mgmt/ extension of NotificationBoard messages with a new object for proper identification.
  • /linklayer/Ieee80211/mgmt/ extension of NotificationBoard messages with a new object for proper identification; introduction of a new function for updating InterfaceTable information; introduction of new NotificationBoard messages for distinguishing new and old WLAN Access Points.
  • /linklayer/radio/ introduction of a new function for Radio module identification and ID setup.
  • /world/ extension with support of multiple radio channels (std::list<int> channels).
  • /world/ extension with support of multiple radio channels.
  • /networklayer/common/ extension with a toolset for managing connection states.
  • /linklayer/ieee80211/mac/ correction of a bug in function handleLowerMsg (inserting a return after line 319.)
  • /transport/TCP/ correction of a bug regarding TCP operation (the TCP connection stucked in state TIME_WAIT).
  • /transport/contract/ correction of a bug regarding TCP socket operation (renewSocket deleted localport/localAddr).


You can download the full source code of HIPSim++ as an exported OMNeT++ 4.x project archive. Steps to import HIPSim++ into the OMNeT++ IDE:

  • open the IDE
  • import the whole project (File -> Import -> General -> Existing Projects into Workspace -> Select <Parent of HIPSim++_DIRECTORY> -> Check HIPSim++ project -> Finish)

Source code of HIPSim++


  • László Bokor, Szabolcs Nováczki, László Tamás Zeke, Gábor Jeney: "Design and Evaluation of Host Identity Protocol (HIP) Simulation Framework for INET/OMNeT++", in the proceedings of the 12-th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWIM 2009), Pages 124-133, ISBN:978-1-60558-616-8, Tenerife, Canary Islands, Spain, Oct. 26. 2009. [PDF] [PPT]
  • László Bokor, László Tamás Zeke, Szabolcs Nováczki, Gábor Jeney: "Protocol Design and Analysis of a HIP-based Per-Application Mobility Management Platform", in the proceedings of the 7-th ACM International Symposium on Mobility Management and Wireless Access (MobiWAC 2009), Pages 7-16, ISBN:978-1-60558-617-5, Tenerife, Canary Islands, Spain, Oct. 26. 2009. [PDF][PPT]
  • Szabolcs Nováczki, László Bokor, Gábor Jeney, Sándor Imre: „Design and Evaluation of a Novel HIP-Based Network Mobility Protocol”, Journal of Networks, Academy Publisher, ISSN: 1796-2056, Volume 3, Issue 1, pp. 10-24, January 2008. [PDF]
  • László Bokor, Szabolcs Nováczki, Sándor Imre: „A Complete HIP based Framework for Secure Micromobility”, 5th @WAS International Conference on Advances in Mobile Computing and Multimedia, MoMM2007, ISBN 978-3-85403-230-4, pp. 111-122., Jakarta, Indonesia, 3-5 December 2007. [PDF]
  • Szabolcs Nováczki, László Bokor, Sándor Imre: „A HIP based Network Mobility Protocol”, SAINTWONEMO 2007 (2007. 01.15-19.), DOI: 10.1109/SAINT-W.2007.8, ISBN: 0-7695-2757-4, INSPEC: 9352994, Hiroshima, Japan, pp.48-52. [PDF]


László BOKOR

Szabolcs Nováczki


Please contact us if you have any questions or ideas how to make the code more precise and the webpage more informative!

Special thanks to

  • László Tamás Zeke
  • and

  • Levente Mihályi
  • and

  • László Csordás
  • and

  • all participants and contributors who are taking part in project OPTIMIX


  • [RFC 4423] R. Moskowitz, P. Nikander: “Identity Protocol (HIP) Architecture”, IETF RFC 4423, May 2006.
  • [RFC 5201] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson: ”Host Identity Protocol”, IETF RFC 5201, April 2008.

  • [RFC 5202] P. Jokela, R. Moskowitz, P. Nikander: ”Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)”, IETF RFC 5202, April 2008.

  • [RFC 5206] P. Nikander, T. Henderson, C. Vogt, J. Arkko: ”End-Host Mobility and Multihoming with the Host Identity Protocol”, IETF RFC 5206, April 2008.

  • [RFC 5203] J. Laganier, T. Koponen, L. Eggert: ”Host Identity Protocol (HIP) Registration Extension”, IETF RFC 5203, April 2008.

  • [RFC 5204] J. Laganier, L. Eggert: “Host Identity Protocol (HIP) Rendezvous Extension”, IETF RFC 5204, April 2008.

  • [RFC 5205] P. Nikander, J. Laganier: “Host Identity Protocol (HIP) Domain Name System (DNS) Extension”, IETF RFC 5205, April 2008.