Host Identity Protocol (HIP) Simulation Framework for INET/OMNeT++
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.
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.
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.
Figure 3. The HIP registration and RVS extension
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.
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.
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:
Please contact us if you have any questions or ideas how to make the code more precise and the webpage more informative!