Mobile data communication based on Host
Identity Protocol
Jonny Mattsson
Mobile data communication based on Host Identity Protocol
Informationsteknik och medieteknik
2010
EXAMENSARBETE
Arcada
Utbildningsprogram:
Identifikationsnummer:
Författare:
Arbetets namn:
Handledare (Arcada):
Uppdragsgivare:
Sammandrag:
Här skriver du in ett sammandrag av hela arbetet. Texten ska fungera fristående och ska
därför vara väl genomtänkt och genomarbetad. Oberoende av förkunskaper ska läsaren
få ett klart och sakligt besked om vad som gjorts, vilka metoder som använts och vilka
resultat man kommit fram till. Inga sådana fakta som inte finns i huvudtexten får finnas
i sammandraget. Inga onödiga förklaringar eller utfyllnadsmeningar ska finnas med.
Sammandraget tar upp ämnesområdet, temat, syftet med arbetet, problemställningen,
begränsningarna, materialet, metoderna, de viktigaste referenserna liksom resultaten
och konsekvenserna av dem. Texten omfattar 200-300 ord, ofta i ett enda stycke. Den är
skriven i presens- eller imperfektform och bildar en helhet som kan stå för sig själv utan
att vara beroende av huvudtexten. Längst nere på sidan skriver du in några nyckelord;
4-8 relevanta substantiv som ger en vink om vad examensarbetet handlar om. Om
arbetet är ett beställningsarbete för ett företag är företagets namn ett av nyckelorden.
Nyckelord:
Sidantal:
Språk:
Datum för godkännande:
2
DEGREE THESIS
Arcada
Degree Programme:
Identification number:
Author:
Title:
Supervisor (Arcada):
Commissioned by:
Abstract:
Write a summary of your whole thesis work here. The text should be able to stand on its
own, and should therefore be logical and well structured. Regardless of the reader’s expertise, the text should provide a clear and factual account of what was done, which
methods were used, and what results were obtained. Do not include in the abstract any
information that is not found in the main text. Exclude any unnecessary explanation or
padding. The abstract describes the subject area, the topic, the aim of the study, the research questions, the limitations, the material, the methods, the main theories and references, the main results and conclusions. The text comprises 200-300 words, often written
as one paragraph. It is written in the present or past tense and forms a whole, which can
stand on its own without being dependent on the main text. Below the text write some
key words; 4-8 relevant words that provide a hint on what the thesis is about. If the thesis
is commissioned by a company, include the company’s name in the key words.
Keywords:
Number of pages:
Language:
Date of acceptance:
3
INNEHÅLL / CONTENTS
1
2
Introduction.......................................................................................................... 8
1.1
Background ................................................................................................................... 8
1.2
Aims and Goals ............................................................................................................. 8
1.3
Structure of thesis.......................................................................................................... 9
Overview of mobility protocols ........................................................................... 9
2.1
2.1.1
3
Mobile IPv6 and MEXT .......................................................................................... 9
2.2
MOBIKE ......................................................................................................................... 9
2.3
HIP ................................................................................................................................. 9
HIP in detail .......................................................................................................... 9
3.1
Arcitechture ................................................................................................................... 9
3.2
Base exchange .............................................................................................................. 9
3.2.1
Controlling message ............................................................................................ 10
3.3
DNS extension............................................................................................................. 15
3.4
ESP protection............................................................................................................. 16
3.5
Rendesvouz server...................................................................................................... 17
3.5.1
3.6
NAT traversal ....................................................................................................... 17
Mobility and Multihoming ............................................................................................. 17
3.6.1
Mobility scenarios ................................................................................................ 17
3.6.2
Client mobility ...................................................................................................... 17
3.6.3
Server mobility ..................................................................................................... 17
3.6.4
Simultaneous mobility.......................................................................................... 17
3.7
4
Mobile IP ........................................................................................................................ 9
Implementations .......................................................................................................... 17
3.7.1
OpenHip .............................................................................................................. 17
3.7.2
InfraHip ................................................................................................................ 20
3.7.3
hip4inter ............................................................................................................... 21
Practical mobility tests based on HIP .............................................................. 21
4.1
Mobile video streaming with VLC ................................................................................ 21
4.1.1
Openhip ............................................................................................................... 21
4.1.2
InfraHip ................................................................................................................ 21
4.1.3
hip4inter ............................................................................................................... 22
4.1.4
"Crosstesting" ...................................................................................................... 22
4.2
Mapping network drive with expandrive ...................................................................... 22
4.3
Text chat with P2P chat application ............................................................................ 22
4.4
Video chat with yawcam .............................................................................................. 25
4
4.5
HIP on smartphones .................................................................................................... 25
4.5.1
Maemo ................................................................................................................. 25
4.5.2
Symbian ............................................................................................................... 25
5
Flash animation on HIP mobility ....................................................................... 25
6
Discussion/conclusions .................................................................................... 25
References ................................................................................................................ 26
Appendices ............................................................................................................... 27
5
Figures
Figure 1: HIP Base Exchange captured with Wireshark ................................................ 10
Figure 2: Data fields of a I1-packet captured with Wireshark. ...................................... 11
Figure 3: Data fields of a R1-packet captured with Wireshark. ..................................... 12
Figure 4: Data fields of a I2-packet captured with Wireshark ....................................... 13
Figure 5: Data fields of a R2-packet captured with Wireshark. ..................................... 14
Figure 6: HIP data as it is stored in a DNS Resource Record ........................................ 15
Figure 7: Supported ESP transform suites. ..................................................................... 16
Figure 8: Content of the hip.conf configuration file. ...................................................... 18
Figure 9: Content of the my_host_identitites.xml file. Content of this file should not be
shared in public............................................................................................................... 19
Figure 10: Content of the known_host_identities.xml file. ............................................ 20
Figure 11: Settings from P2P chat application showing that the communication is based
on a LSI-address. ............................................................................................................ 23
Figure 12: Screenshot from P2P chat application that shows how the chat continues
uninterrupted even if one of the client gets a new IP-address. ....................................... 24
Abbreviations
DNS
Domain Name System
RR
Resource Record
TCP
Transmission Control Protocol
IP
Internet Protocol
UDP
User Datagram Protocol
Definitions
Host Identity Tag (HIT)
A HIT is a 128bits value calculated as a cryptographic hash from a Host Identity
Host Identity (HI)
A hosts identity is represented by the public part of a public-private RSA or DSA keypair. Must be unique.
6
Local Scope Identifier (LSI)
A 32bits value that can be used as an IPv4-address.
HMAC
A HMAC is a message authentication code that is calculated over the entire packet excluding the SIGNATURE-parameter.
Security Parameter Index (SPI)
A numeric value that is chosen by each host when setting up a ESP Security Association
for combining right packet with right SA.
7
1
INTRODUCTION
This B.SC thesis contains an overview of mobility protocols with focus on Host Identity
Protocol (HIP). A mobility protocol in this thesis is defined as a protocol that can make
traditional TCP/IP communication mobile. The main goal of this thesis is to examine
HIP: s mobile preferences by doing practical tests on common scenarios such as chatting and video streaming. This thesis is a part of the WISEciti research project. WISEciti stands for Wireless Community Services for Mobile Citizens and is collaboration
between Research Institutions and companies.
1.1 Background
Traditional TCP/IP communication doesn’t offer the possibility for the user to become
mobile. In traditional network architecture the IP-address is used to both identify communicating hosts and locate the host’s network position. If a client switch to a new IPaddress all communications is interrupted. Mobility protocols such as Mobile IP and
HIP is designed from that problem. By introducing a new namespace, Host Identity
namespace, and an new layer in the TCP/IP stack HIP separates the locator and identifier from each other (Moskowitz & Nikander, 2006) Mobile IP solves the mobility problem by using two IP-addresses.
1.2 Aims and Goals
The main goal of this thesis is to describe different protocols that provide mobile data
communication. One of the protocols, HIP, will be described in detail and practical tests
to evaluate its mobility preferences will be performed. All three HIP-implementations
that are developed until the writing of this thesis will be evaluated.
The aim of this report is to show how data communication can be mobile, especially
data communications that are used by common people on a daily bases.
8
1.3 Structure of thesis
This thesis contains two sections. The first section is a theoretical part that describes
different mobile protocols with a detailed description of HIP. The second part is practical section that contains all the mobility tests that are performed with HIP. This part
shows how the tests are performed, which settings are used and contains results and illustrations of the tests
2 OVERVIEW OF MOBILITY PROTOCOLS
2.1 Mobile IP
2.1.1 Mobile IPv6 and MEXT
2.2 MOBIKE
2.3 HIP
3 HIP IN DETAIL
3.1 Arcitechture
3.2 Base exchange
HIP base exchange (Fig. 1) is a four-way handshake between two hosts (Moskowitz …
2008) The host that starts the base exchange is called initiator and the host is called responder. The first packet, I1, is used to trigger the exchange and the three others, R1, I2,
R2, are used to generate a session key based on Diffie-Hellman key exchange.
9
Figure 1: HIP Base Exchange captured with Wireshark
3.2.1 Controlling message
I1
This is the initiator packet that is sent from the host that tries to make a HIP-connection
to the other part. The I1-packet (Fig 2.) contains the own hosts HIT and, if known, the
responders HIT. If the responders HIT is unknown it has value NULL and opportunistic mode is used. Opportunistic mode is not recommended to use as it is more vulnerable to Man-In-The-Middle attacks.
If a Rendezvous server is used, I1 packet is sent to the Rendezvous server instead of to
the responder. The Rendezvous server looks up the IP-address of the recipient and
transmits the I1 packet to the recipient.
After an I1 packet is sent, a timer is started at the initiator. If the R1 packet is not received before a chosen timeout the initiator retransmits the I1 packet and restarts the
timer.
10
Figure 2: Data fields of a I1-packet captured with Wireshark.
R1
This is the packet that the responder sends, as a respond to the I1 packet, to the initiator.
An R1 packet (Fig 3.) contains the Diffie-Hellman key, a cryptographic puzzle and the
responder’s public key. The responder uses its public key to sign the packet. The cryptographic puzzle contains a random number and a difficulty.
11
Figure 3: Data fields of a R1-packet captured with Wireshark.
I2
This is the second packet from the initiator and is a respond to the R1 packet. A I2
packet (Fig 4.) contains a solution to the cryptographic puzzle and Diffie-Hellman values. A hash message authentication code(HMAC) is included in the packet and is used
as an additional protection against attacks. The packet is signed before the transmission.
12
Figure 4: Data fields of a I2-packet captured with Wireshark
R2
R2 is the second packet (Fig 5.) from the responder and is a respond to the I2 packet. It
contains a HMAC and a HIP_SIGNATURE. R2 is the fourth and the last packet in HIP
Base Exchange and if the puzzle is solved and all parameters are correct a HIP- connection is established and data can flow between the two hosts.
13
Figure 5: Data fields of a R2-packet captured with Wireshark.
UPDATE
This packet is used to send information about the HIP association to the other part.
When a host changes its network location an update packet is sent to the other part containing its new IP-address. If a update parameter contains a SEQ parameter the responder needs to confirm the UPDATE with a ACK-parameter.
NOTIFY
This packet is used to inform the other host about protocol errors and negotiation failure. NOTIFY packet is a purely information packet.
CLOSE
14
This packet is used to terminate the existing HIP-association and contains a HMAC and
a HIP_SIGNATURE.
CLOSE_ACK
This packet is sent in respond to a CLOSE packet and confirms the shutdown of a HIPassociation. A HIP_SIGNATURE is included for verifying its validity.
3.3 DNS extension
To continue using human-friendly domain names with HIP all DNS-servers needs to be
modified. According to HIP DNS extension (Nikander & Laganier) an HIP Rescource
Record will be stored in DNS. A HIP RR (Fig 6) contains a HI, HIT and optional a domain name or IP-address to a Rendezvous server. Because a HIT has the same length as
an IPV6 –address it can be stored in an AAAA record.
Figure 6: HIP data as it is stored in a DNS Resource Record
15
3.4 ESP protection
For protecting user data HIP uses Encapsulated Security Payload (ESP) (Jokela, Moskowitch & Nikander). During base exchange a pair of Security Associations (SAs) is
established, one in each direction, by modifying parameters in the HIP packets.
The responder begins the negotiations by adding a new ESP_TRANSFORM parameter
to the R1-packet. An ESP_TRANSFORM message contains information of which ESP
transform suites a host is prepared to use. Transform suites are limited to six and are
stored in preferred order (Fig. 7)
The Initiator responds to the R1-packet by selecting one of the suggested transforms and
adds that information in an ESP_TRANSFORM parameter in the I2-packet. An
ESP_INFO containing a own chosen Security Parameter Index (SPI) value is also included in this packet.
The responder responds to the I1-packet by including its own chosen SPI value in the
R2-packet.
HIP ESP packets are very similar to IPsec ESP packets. Only difference is that a HIP
ESP packet doesn’t contain host identifiers. Instead the SPI:s are used to locate right SA
for received packets.
Figure 7: Supported ESP transform suites.
16
3.5 Rendesvouz server
3.5.1 NAT traversal
3.6 Mobility and Multihoming
3.6.1 Mobility scenarios
3.6.2 Client mobility
3.6.3 Server mobility
3.6.4 Simultaneous mobility
3.7 Implementations
Presently there are three major implementations of HIP, OpenHIP that is developed by
Boeing Company, InfraHIP that is developed by Helsinki Institue of Information technology and hip4inter that is developed by Oy LM Ericsson Ab.
3.7.1 OpenHip
OpenHIP is a open source HIP-implementation developed by Boeing Company. OpenHIP supports following Operating Systems: Linux, BSD, Mac OS X, and Windows XP,
vista and 7. OpenHIP uses XML library for configurations files and supports SHA,
MD5, HMAC hashing and 3DES, BLOWFISH, AES encryption (Boeing Company,
2010)
Using OpenHIP
After OpenHIP is installed an icon is placed in Windows task bar (Fig #).
When right-clicking on the icon a menu appears. From the menu the user can reach the
configuration files.
17
The hip.conf (Fig 8) is auto generated when installing and contains all the HIP-options.
Figure 8: Content of the hip.conf configuration file.
The my_host_identities.xml (Fig 9) contains information about the own host identity i.e.
the public and private key. It also contains the HIT, which is calculated upon the public
key, and a LSI.
18
Figure 9: Content of the my_host_identitites.xml file. Content of this file should not be shared in public.
The known_host_identities (Fig 10) contains information about other known host identities. It is used to locally map a HIT or LSI with a IP-address when not using a DNS.
Therefore a hosts HIT, LSI, IP and optional a Rendezvous server is stored in this file.
19
Figure 10: Content of the known_host_identities.xml file.
3.7.2 InfraHip
InfraHip is a open source HIP-implementation developed by HIIT, Helsinki Institue of
Information technology. Only supported operating systems are those who works on
Linux 2.6.
20
Using InfraHip
InfraHips HIP-daemon can be started with the following command: /usr/sbin/hipd.
Hosts own HI and HIT is stored in /etc/hip. If a DNS is not in use known HIT: s and IPaddresses can be stored in /etc/hip/hosts or mapped by following command: hipconf add
map [HIT] [IP]
3.7.3 hip4inter
4 PRACTICAL MOBILITY TESTS BASED ON HIP
4.1 Mobile video streaming with VLC
The purpose of this test was to make a video stream mobile. VLC 1.0.3 player was used
as both streaming server and client. All three implementations, OpenHip, InfraHIp and
Hip4Inter, were first tested separately and then “crosstested”. In all tests the server part
was a virtual machine in hip.arcada.fi domain. All clients were attached to hip.arcada.fi
network through a network wire. Mobility was tested by pulling of the wire and switch
to a wireless network in arcada.fi domain.
4.1.1 Openhip
The stream was started by choosing UDP as protocol and the clients LSI as address(Fig
#) The stream can also use the HIT instead of the LSI.
4.1.2 InfraHip
The stream was started from the command line with following command:
vlc–vvv[FILENAME.AVI]--ipv6--sout
‘#std{access=udp,mux=ts,dst=[2001:0012:4b7a:4a66:ac4d:7141:40ff:71ae]:1234}’
21
The stream was received with the following command:
vlc -vvv 'udp://@[::]:1234'
//BÖR KOLLAS
4.1.3 hip4inter
4.1.4 "Crosstesting"
4.2 Mapping network drive with expandrive
4.3 Text chat with P2P chat application
The purpose of this test was to show how a chat can continue uninterrupted if it is based
on a HIP-connection. The chat application that was used in this test is a simply messaging application developed by Jonas F. Jensen. P2P chat is released under the GNU GPL
license.
The test was performed on two computers that were in the same LAN. Both computers
had Windows XP SP3 as operating system and OpenHip as HIP-software. HIPconnection was establishes by using LSI(Fig 6). Mobility was tested by pulling of the
wire of one of the clients and switch to a wireless network that offers IP-adresses in
same addres space. The test was successful (Fig 7)
22
Figure 11: Settings from P2P chat application showing that the communication is based on a LSI-address.
23
Figure 12: Screenshot from P2P chat application that shows how the chat continues uninterrupted even if one of the
client gets a new IP-address.
24
4.4 Video chat with yawcam
4.5 HIP on smartphones
4.5.1 Maemo
4.5.2 Symbian
5 FLASH ANIMATION ON HIP MOBILITY
6 DISCUSSION/CONCLUSIONS
25
REFERENCES
Moskowitz, R & Nikander P. (2006). Host Identity Protocol (HIP) Architecture, IETF
RFC 4423. Retrieved Mars 1, 2010 from http://tools.ietf.org/html/rfc4423
Moskowitz R, Nikander P, Jokela P, & Henderson T (2008). Host Identity Protocol.
RFC 5201. Retrieved Mars 1, 2010 from http://tools.ietf.org/html/rfc5201
Moskowitz R, Nikander P & Jokela P(2008). Using the Encapsulated Security Payload
(ESP) Transport Format with the Host Identity Protocol (HIP) Retrieved Mars 1, 2010
from http://tools.ietf.org/html/rfc5202
26
APPENDICES