You are on page 1of 9

Host Identity Protocol

Fayez Al-Shraideh
Networking Laboratory,
Helsinki University of Technology
fayez.al-shraideh@hut.fi / fayez.al-shraideh@nokia.com

Abstract
2. HIP Architecture Overview
Host Identity Protocol (HIP) proposes a new name
space, Host Identity. This name can be any globally 2.1. Host Identity Namespace
unique name but it has been chosen to be the Public
Key of a Public/Private Key pair. Host Identifier (HI) is a name in the Host Identity
This paper can be seen as HIP tutorial since it namespace. The public key of a public/private key pair
provides an insight view on HIP Architecture, HIP is a static globally unique name and it has been chosen
Base Exchange, Encapsulated Security Payload (ESP) by HIP Specification as an HI. Authentication and
Security Association Setup, mobility and multi-homing, protection of man-in-the-middle attacks is possible
and some early experiences about HIP. using a public key based HI. Rivest Shamir Adelman
(RSA) public key algorithm must be supported by all
1. Introduction HIP hosts and the Digital Signature Algorithm (DSA)
should be supported also.
The current Internet is based on two main Host Identity Tag (HIT) is a 128-bit static globally
namespaces, the Domain Name Service (DNS) names unique cryptographic SHA-1 hash over the HI. There
and the Internet Protocol (IP) addresses. DNS are two types of HITs:
namespace has enriched the Internet by helping its • Type one is generated by taking the least
users to use the Internet easier by allowing them to significant 128-bits of the SHA-1 hash of the
specify meaningful names to different services in the HI. The first two bits are modified to make a
network. The role of the DNS is derived from the difference between the HIT and IPv6 address.
difference between humans and computers. • Type two consists of a Host Assigning
IP address namespace describes both the host Authority Field (HAA) concatenated with the
topological location in the network, and the host least significant 64-bits of SHA-1 hash of HI.
identity. The dual operation of the IP address causes The HIT type is defined in both Sender HIT
problems when the host has to change its IP address Type (SHT) and Destination HIT Type (DHT)
due to e.g. mobility. The location information changes, fields in HIP controls. HIT has a fixed length
but it should not affect the identity information of the regardless of the cryptographic algorithm used
host. IP address is overloaded and it has to be only to generate the public key (i.e. HI), and the
locator. A new naming should be defined to act as a usage of HIT will ease protocol encoding.
stable Host Identity to ease up mobility and to make it Local Scope Identifier (LSI) is a 32-bit or a 128-bit
happen in a straightforward manner. [1] local representation of HI. LSI is meant for IPv4 or
Host Identity Protocol (HIP) introduces a separation IPv6 based applications. 32-bit and 128-bit LSIs are
between the host identity and location identity. The IP allocated from a TBD IPv4 subnet and a TBD IPv6
address remains as the locator, while a new namespace subnet, respectively. The low order 24-bits of HIT
is introduced for host identifiers. represent the low order 24-bits of IPv4-compatible
HIP is specified by HIP Working Group at IETF LSI, while The low order TBD-bits of HIT represents
[1], [2], [3], [4], [5], and [6]. the low order TBD-bits of IPv6-compatible LSI.
In the next chapters, I will discuss the HIP
Architecture Overview, more details about HIP as a
Protocol, how HIP can support mobility and multi-
homing, and some experiences about HIP.

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
2.2. New Stack HIP. Chapter six, Mobility and multi-homing, will
discuss further how HIP handles host mobility.
HIP introduces a new layer in the TCP/IP stack: When a source host wants to send some traffic to a
Host Identity Layer. The new layer is located between destination host, the application process at the sender
the networking layer and the transport layer as shown has to resolve the destination FQDN using e.g. DNS
in figure one. query. The DNS replies with the corresponding
destination HIT and IP address of the receiver. After
resolving the location information, the host initiates the
Process HIP Base Exchange (described later in more detail).
The purpose of the Base Exchange is to authenticate
Sockets the peer host and to create needed keying material for
the HIP association and ESP Security Associations.
<HIT, port> pairs The ESP SA setup is specified in [3] (described later in
Transport Layer more detail). Currently ESP is defined as a mandatory
transport format, but there can be other transport
formats defined in the future.
Host Identifier
Host Identity Layer
3. HIP Protocol
Translation
Before going into the details of the HIP Base
IP Address Exchange protocol, it is time to introduce the HIP
Internetworking Layer Format. It would be easier to understand the details of
Translation HIP Base Exchange if the HIP packets format is in
mind all the time, but I will not go into the very details
of HIP Parameters.
Link Layer Link Layer Address
Figure 1: New Stack [14]&[11]&[8] 3.1. HIP Packets Format
The new layer hides IP addresses from the layer Next Payload Len Type VER RES
Header
above it. Applications see only HITs or LSI instead of 8-bits 8-bits 8-bits 4- 4-bits
HIP Header

IP addresses. The actual translation between the bits


HIT/LSI and the IP address is made at the new layer. Controls Checksum
With this new approach, the application process is 16-bits 16-bits
bound to a socket that consists of the HIT and port pair Sender’s HIT
[12] regardless of any IP address the host is using in 128-bits
the Internetworking layer. The application process will Receiver’s HIT
not deal with destination IP addresses any more and it 128-bits
has to use destination HIT instead. HIP Parameters (in TLV Format)
Mapping of HIT to IP address should happen to Max length 2008 bytes
facilitate locating the destination in the network
topology. The initial mapping between IP addresses Figure 2: HIP Packets Format [2]
and HITs can be retrieved e.g. from the DNS. Then the
The common HIP header for all packets, as shown
well-known mapping from IP address to Link Layer
in figure two, contains the fields:
Address (i.e. Address Resolution Protocol ARP in
• Next Header: it is not utilized in current HIP
Ethernet) should be done in each network segment in
specification and its value is Decimal 59, which
the path. The decoupling between Transport and
corresponds to no next header in IPv6
Networking layers will help in the evolution of any of
specification.
them separately from each other.
The dynamic mapping between the Identifier and • Payload Length: it determines the total length
Locator makes it easier to change the locator of a HIP packet starting from the Sender’s HIT
information when the host changes its location. If the field (Sender’s HIT, Receiver’s HIT, and HIP
destination host is moving to another network segment, Parameters) in 8-byte units. If the Payload
it has to change its IP address only and this new Length has decimal value of four, that means
address has to be communicated to source host using the HIP packet does not contain any HIP

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
parameters; so value four is the minimum value I1
the Payload Length can have.
Header:
• Type: this value determines HIP packet type. Packet Type = 1
(i.e. I1 is type one, R1 is type two, I2 is type SRC HIT = Initiator's HIT
three, and R2 is type four) DST HIT = Responder's HIT, or NULL
• Version: this field determines the version IP(HIP())
number of HIP; its current value is one.
• Reserved: this is reserved for future use. Figure 4: I1 [2]
• Controls: in this field the sender’s HIT and R1 is a HIP type two packet, as shown in figure
receiver’s HIT types are specified. This field is five, and is sent as a reply to I1 packet. The main
used to signal some information to the peer HIP functions of R1 packet are
node, like certificate or “more is following this • The Puzzle Challenge
packet”, or “my HI is anonymous”. • Diffie-Hellman key agreement
• Checksum: this field has to be recomputed for • Encryption and integrity protection capability
different lower layer protocols (i.e. IPv6 or exchange
IPv4). HIP Parameters that can be used in R1 packet are
• Sender’s HIT and receiver’s HIT are 128-bits shown in figure five. (i.e. R1_COUNTER, …,
each and either type 1 or 2 according to HIP ECHO_REQUEST)
Controls field. The responder can optionally specify the current
HIP parameters follow the common header, and generation of the valid puzzles (R1_COUNTER is
they define HIP-signaling information that is used for this purpose), which means that the solution to
exchanged between HIP peers. They are encoded in old generation puzzles is not valid anymore. So the
Type Length Value (TLV) format. The real meaning of Initiator has to include a copy of this counter in the I2
HIP parameters can be seen, when the details of HIP packet to show that it has used the current valid puzzle.
Base Exchange are illustrated. The puzzle consists of a random number #I and
difficulty K. The Diffie-Hellman key agreement is a
3.2. HIP Base Exchange protocol for exchanging a secret key over an insecure
medium without any prior secrets. This shared secret
will be used in the encryption algorithms.
Initiator Responder DIFFIE_HELLMAN Parameter defines the Diffie-
I1 Hellman parameters (i.e p, g, and Diffie-Hellman
public key that equals to “gResponderSecret mod p”). The
R1 values of p and g are specified through the chosen
Modular Exponential Group (MODP) ID and both the
I2 initiator and the responder have to agree on those
values.
R2 HIP_TRANSFORM parameter defines the
encryption and integrity protection algorithms
supported by receiver.
Figure 3: HIP Base Exchange [2] The Host Identity, including the used algorithm
Figure three shows the four-way handshake (RSA or DSA), and the FQDN are defined in the
between two hosts wanting to initiate communication. HOST_ID parameter.
This is called HIP Base Exchange and it can be viewed The receiver has the possibility to request an echo
as a lightweight version of IKE [9]. I1 packet is the back to some data it is sending. ECHO_REQUEST
first packet sent in the handshake and it is an parameter is used for this purpose, and in this case the
unencrypted and unsigned packet, meaning that the initiator has to use the ECHO_RESPONSE parameter
Initiator would like to talk HIP with the responder. The in the reply.
responder’s IP address can be derived from the DNS. R1 packet is signed and the signature is encoded in
I1 is a HIP type one packet, as shown in figure four, the HIP_SIGNATURE_2 parameter. This HIP
and it is very simple one with no HIP parameters. parameter defines the signature value and the used
Responder is protected from I1 replays by the use of signature algorithm (RSA or DSA). The signature is
pre-computed R1s as will be discussed later. calculated after zeroing destination HIT, checksum
field, puzzle random number #I, and opaque fields.
There are two types of ECHO_REQUEST parameter,

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
the signature covers one type and does not cover the mod p”)[13]. The values of p and g are specified
other. responder can choose which type to use. through the chosen Modular Exponential Group
It is possible for the receiver to have pre-computed (MODP) ID [7], which has to be copied from R1 since
R1s to minimize the effect of denial-of-service attacks. both the initiator and the responder have to use the
This is why HIP_SIGNATURE_2 parameter is used in same value. So initator can calculate the Diffie-
R1; it does not cover the destination HIT, puzzle Hellman secret key as (gResponderSecret mod p) InitiatorSecret
random number #I, and opaque fields. These fields can mod p. Now the Initiator can generate the keying
be added later, when R1 is sent. material, as explained in details in [2], which will be
One or more certificates can follow R1 packet, and used in chosen encryption and integrity protection
responder should notify the initiator about this by using algorithms.
the C-bit in controls field of the HIP Header. With HIP_TRANSFORM parameter, initiator can
Responder’s Host Identity can be anonymous; this can select encryption and integrity protection algorithm
be signaled to initiator by setting the A-bit in controls from the alternatives offered by responder.
field of the HIP Header. Initiator’s HI is encrypted using the selected
Initiator is protected from R1 replays using the encryption algorithm (as in HIP_TRANSFORM), and
R1_COUNTER (R1 generation counter). The counter the HI digest is encoded in ENCRYPTED HIP
value is incremented by the Responder every time it parameter. The keying material generated after Diffie-
sends an R1 packet. Hellman key agreement is used as encryption key in all
further encryption or integrity protection algorithms.
R1 ECHO_RESPONSE parameter is sent as a reply to
Header: ECHO_REQUEST parameter that sent in R1 packet.
Packet Type = 2 ECHO_RESPONSE can be covered by signature
SRC HIT = Responder's HIT calculation encoded in HIP_SIGNATURE, and in this
DST HIT = Initiator's HIT case it has different type than the one that is not
covered by signature.
IP ( HIP ( [ R1_COUNTER, ] I2 packet's integrity is protected using keyed-hash
PUZZLE, message authentication code (HMAC): The resulting
DIFFIE_HELLMAN, hash is different if the packet has been altered on its
HIP_TRANSFORM, way. HMAC also provides I2 packet's authenticity
HOST_ID, because only someone who knows the secret key could
[ ECHO_REQUEST, ] have generated a valid HMAC. HMAC covers all HIP
HIP_SIGNATURE_2 ) packet except the HIP parameters following it (i.e.
[, ECHO_REQUEST ]) HIP_SIGNATURE).
HIP_SIGNATURE contains the I2 packet signature.
Figure 5: R1 [2]
This HIP parameter defines the signature value and the
When the Initiator receives an R1 packet, it has to used signature algorithm (RSA or DSA). The signature
check the R1 signature and solve the puzzle. is calculated after zeroing checksum field, and it covers
I2 packet shown in figure six is a HIP type three the whole I2 packet except the HIP parameters
packet sent by the Initiator as a reply to R1, and its following it.
main purposes are: As in case of an R1 packet, one or more certificates
• Puzzle solution delivery can follow I2 packet, and setting the C-bit in controls
• Diffie-Hellman key agreement [13] field of the HIP header makes the notification for this.
• Encryption and integrity protection selection. Initiator’s Host Identity can be anonymous and this can
HIP parameters that can be used in I2 packet are be signaled to responder by setting the A-bit in
shown in figure six. (i.e. R1_COUNTER, SOLUTION controls field of the HIP header.
,…, ECHO_RESPONSE) Responder is protected from I2 replays by the
R1_COUNTER HIP parameter is used to signal cookie mechanism (PUZZLE in R1, SOLUTION in I2)
back to responder what generation of puzzle was and by the echo mechanism (ECHO_REQUEST in R1,
solved. The value of this parameter has to be the same ECHO_RESPONSE in I2). I2 packet's integrity is
as the one in R1 packet. verified in HMAC verification (less expensive than
The puzzle solution is encoded in the SOLUTION signature verification) and I2 packet signature
HIP parameter. DIFFIE_HELLMAN Parameter verification.
defines the Diffie-Hellman parameters (i.e p, g, and
Diffie-Hellman public key that equals to “gInitiatorSecret

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
I2
Header: Sender Receiver
Type = 3
SRC HIT = Initiator's HIT CLOSE
DST HIT = Responder's HIT
CLOSE_ACK
IP ( HIP ( [R1_COUNTER,]
SOLUTION, Figure 8: Closing HIP Association [2]
DIFFIE_HELLMAN,
CLOSE is packet type three, as in figure nine,
HIP_TRANSFORM,
which has to contain ECHO_REQUEST HIP
ENCRYPTED { HOST_ID },
parameter in addition to the basic ones HMAC and
[ ECHO_RESPONSE ,]
HIP_SIGNATURE. Sender uses ECHO_REQUEST
HMAC,
for validation purposes; receiver has to send back
HIP_SIGNATURE
ECHO_REPLY inside CLOSE_ACK HIP Packet
[, ECHO_RESPONSE] ) )
shown in figure ten.
Figure 6: I2 [2]
Upon reception of I2 packet, responder can CLOSE
calculate the Diffie-Hellman secret key as (gInitiatorSecret Header:
mod p)ResponderSecret mod p. Responder can now generate Packet Type = 8
the keying material, and it is capable of using it in SRC HIT = Sender's HIT
encryption and integrity protection algorithms. DST HIT = Recipient's HIT
R2, as shown in figure seven, is a HIP packet type
four that completes the HIP Base Exchange. It is a IP ( HIP ( ECHO_REQUEST, HMAC,
reply for I2 packet. HIP_SIGNATURE ) )
R2 packet has two HIP parameters. The first one is
Figure 9: CLOSE [2]
HMAC_2, which contains the HMAC calculated over
the whole HIP packet, except the HIP parameters (i.e.
HIP_SIGNATURE) following the HMAC_2, CLOSE_ACK
concatenated with responders HOST_ID parameter, Header:
but this HOST_ID parameter is removed from R2 Packet Type = 9
packet. So HMAC_2 is an HMAC calculated as if SRC HIT = Sender's HIT
HOST_ID parameter is present but it is not. The DST HIT = Recipient's HIT
second R2 HIP parameter is HIP_SIGNATURE, which
covers the whole R2 packet. Initiator is protected from IP ( HIP ( ECHO_REPLY, HMAC,
R2 replays by HMAC verification, which is less HIP_SIGNATURE ) )
expensive than signature verification.
Figure 10: CLOSE_ACK [2]
R2 As a conclusion, HIP Base Exchange is a two-way
Header: host authentication mechanism and key material
Packet Type = 4 generation method.
SRC HIT = Responder's HIT
DST HIT = Initiator's HIT
IP ( HIP ( HMAC_2, HIP_SIGNATURE )
)
Figure 7: R2 [2]
After the Base Exchange, there is no difference
between the Initiator and Responder any longer.
Closing HIP association, shown in figure eight, can
happen by sending CLOSE HIP packet either from
initiator or responder, and it has to be acknowledged
by CLOSE_ACK Packet.

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
3.3. HIP Encapsulated Security Payload (ESP)
Setup protocol
UPDATE
Header:
Initiator Responder Packet Type = 6
I1 SRC HIT = Sender's HIT
DST HIT = Recipient's HIT
IP (HIP ( [SEQ, ACK, ] HMAC,
R1(ESP_TRANSFORM) HIP_SIGNATURE ))

I2(ESP_TRANSFORM, ESP_INFO) Figure 12: UPDATE [2]


SEQ HIP parameter is used, if there is a need for
R2(ESP_INFO) acknowledge from the peer host. No SEQ HIP
parameter in the UPDATE packet means that no
Figure 11: HIP Base Exchange acknowledge is needed, and this UPDATE packet is an
combined with acknowledgement to previous UPDATES from the
peer Host.
HIP ESP Setup Protocol [3]
ACK HIP parameter is used to acknowledge the
Encapsulated Security Payload (ESP) is the UPDATE packet with SEQ HIP parameter coming
transport protocol that will be used for host-to-host from peer HOST. ACK should echo the SEQ value of
user data communication. HIP base exchange the coming UPDATE packet.
described in the previous section does not have any There are other HIP parameters that can be used to
indication for ESP or data transport format. New HIP support host mobility, rekeying, and ESP SA update or
parameters have been added to R1, I2, and R2 packets addition.
to support ESP setup.
Figure 11 shows the HIP Base Exchange combined 4. Mobility and Multi-Homing
with ESP setup protocol; this message sequence will
create both HIP association and ESP security When a host moves from one network to another, it
associations. has to change its location information, i.e. the IP
ESP_TRANSFORM HIP parameter, in R1 packet, address. When HIP is used, this change will have no
is used by responder to inform about ESP encryption effect on the upper layer protocol (TCP, UDP, …)
and authentication algorithms alternatives that it can since they are bound to HI and not to the IP Address.
support. Initiator will choose one of the offered ESP Still, the IP Address is the locator of the host and in
encryption and authentication algorithms and will order to be reachable by its peers, they have to be
specify the Security Parameter Index (SPI) that should informed about the new IP Address.
be used by the responder for the ESP SA. IP address is not used as SA selector; the SPI value
ESP_TRANSFORM and ESP_INFO HIP parameters, combined with the destination HI is the SA selector.
in I2 packet, carry the chosen algorithm and SPI value But due to the importance of anti-replay service in
respectively. The Responder has to inform the Initiator ESP; it is very necessary to have some kind of
about the SPI value that must be used for data packets association between SPI and IP address (i.e. different
towards the Responder in the ESP SA. ESP_INFO in SA for each Interface). Anti-replay service is window
the R2 packet is used for this purpose. Both the SPI based and it is sensitive for latency, so if one of the
and the destination host IP address can identify the SAs is using different IP addresses, packets will use
host context. different paths and some of them will fall outside the
It is necessary to update HIP association due to: ESP anti-replay window.
• Expiry of ESP SA; since every SA is bound to LOCATOR is the key HIP parameter that enables
a lifetime. host mobility, host multi-homing, and site multi-
• Addition of new SA. homing. This HIP parameter is carried usually in HIP
• Host IP address change. UPDATE packet. When either the mobile host or the
Update, HIP packet type six as shown in figure 12, peer host wants to create a new inbound SA, NES HIP
is used for this purpose. parameter has to be used in the HIP UPDATE packet.

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
4.1. Some Mobility Scenarios

Figure 13 shows one mobility scenario for a mobile Mobile Host Peer Host
host that has an active HIP Association with a peer UPDATE(LOC(SPI-IP),SEQ)
host (i.e. HIP Association and ESP SAs negotiated and
created). The Mobile Host moves to another network UPDATE(NES,SEQ,ACK,D-H,ECHO-REQ)
and changes its IP address. So it has to inform the peer
host about this change by an acknowledged HIP
UPDATE packet, and it uses LOCATOR HIP UPDATE(NES,SEQ,ACK,D-H,ECHO-RES)
parameter to specify the inbound SPI-new IP address
association. Peer host will get this UPDATE and UPDATE(ACK)
acknowledge the new change by sending another Figure 15: Readdress with peer-initiated re-
acknowledged HIP UPDATE packet with its inbound keying [4]
SPI, and it will check the address by using the ECHO
mechanism (ECHO-REQUEST/ECHO-REPLY). Figures 16 and 17 show the readdressing scenario
Mobile host will acknowledge this and send the for multi-homed mobile host in the case of one or two
ECHO-REPLY in HIP UPDATE packet. So from now IP addresses change.
on, the new mobile host IP address will be the
destination IP address of IP packets for the inbound SA
and the source IP address for the outbound SA. Multihomed Host Peer Host
UPDATE(LOC(SPI-IP),NES,SEQ,D-H)

Mobile Host Peer Host UPDATE(NES,SEQ,ACK,D-H,ECHO-REQ)


UPDATE(LOC(SPI-IP),SEQ)
UPDATE(ACK,ECHO-RES)
UPDATE(SPI,SEQ,ACK,ECHO-REQ)
Figure 16: Readdress in Basic multihoming
UPDATE(ACK,ECHO-RES) with mobile-initiated re-keying (one IP address
in LOC) [4]
Figure 13: Readdress without re-keying, but
with address check [4]
Multihomed Host Peer Host
The scenario in figure 14 is different than previous
one, there is a new SA and at the same time a new IP UPDATE(LOC(SPI1-IP1,SPI2-IP2),SEQ)
Address and there is re-keying initiated by the Mobile
Host. Further, in figure 15, the Peer Host initiated the UPDATE(ACK)
re-keying.
to IP1: UPDATE(SPI,SEQ,ECHO-REQ)

Mobile Host Peer Host UPDATE(ACK,ECHO-RES)


UPDATE(LOC(SPI-IP),NES,SEQ, D-H)

UPDATE(NES,SEQ,ACK,D-H,ECHO-REQ) to IP2: UPDATE(SPI,SEQ,ECHO-REQ)

UPDATE(ACK,ECHO-RES) UPDATE(ACK,ECHO-RES)

Figure 14: Readdress with mobile-initiated re- Figure 17: Readdress in Basic multihoming
keying [4] (two IP Addresses in LOC) [4]
The message sequence in figures 13, 14, 15, 16, and
17 is based on old HIP specification since it uses some
HIP parameters (i.e. SPI and NES), which are not
present in the latest IETF HIP specification. HIP

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
mobility management specification has to be updated HIP Mobility Management is considered to be
to be consistent with the latest HIP specification. "macro mobility" and some kind of micro-mobility
support is required to further enhance the mobility
4.2. HIP and Rendezvous Extension management.
HIP has a great potential in performance, security,
To be able to reach a HIP host in the Internet, the addressing architecture and all those are advantages
initial IP address has to be stored somewhere. over Mobile IP. In a mobile network infrastructure,
Traditionally, the DNS is used for storing this mobile IP has advantage over HIP. [9]&[10]
information. The problem with the DNS system is the HIP is still in the development phase and there is
latency; updating the location information each time still inconsistency in HIP IETF drafts. HIP as a
the mobile node moves, the update is not fast enough. protocol is very adaptive to functionality changes and
The Rendezvous mechanism is designed to solve its clearly visible from its format, figure two, that it is
this problem; the DNS contains only the location easy to add new feature or functionality by adding a
information of the Rendezvous point and all Mobile new HIP parameter or might be a new packet. HIP is
Host location updates are done at the rendezvous point. still evolving and we might see completely new
Rendezvous server provides HIP reachability features coming in the future.
service to its clients. In order to be reachable by any
other host, each host has to register to rendezvous 10. References
(RVS) server in its area and this server has to be
updated with the latest reachable IP addresses of the [1] draft-ietf-hip-arch-02.txt, January 11, 2004, Expires:
mobile host. The RVS server IP address is configured July 11, 2004, http://www.ietf.org/internet-drafts/draft-
with a specific resource record (RR) HIPRVS as well ietf-hip-arch-02.txt
as the HI(HIT) with HIPHI in DNS. [5]&[6]
[2] draft-ietf-hip-base-02, February 21, 2005, Expires:
So if some host wants to create a HIP association
August 25, 2005,
with a destination host registered in RVS server, the http://www.hip4inter.net/documentation/drafts/draft-
source host will resolve the destination FQDN from ietf-hip-base-02.txt
DNS, DNS will reply by its HIPRVS and HIPHI, then
the source host can use the RVS server IP address to [3] draft-jokela-hip-esp-00, February 11, 2005, Expires:
send the I1 HIP packet to RVS server which will relay August 12, 2005,
it to the right responder and just after that the R1, I2, http://www.hip4inter.net/documentation/drafts/draft-
and R2 packets will be directly between both of the jokela-hip-esp-00.txt
hosts.
[4] draft-ietf-hip-mm-01, February 20, 2005, Expires:
August 21, 2005, http://www.ietf.org/internet-
5. Experience with HIP drafts/draft-ietf-hip-mm-01.txt

Thomas R. Henderson, Jeffrey M. Ahrenholz, and [5] draft-ietf-hip-dns-01, February 20, 2005, Expires:
Jae H. Kim have implemented an experimental HIP August 21, 2005, http://www.ietf.org/internet-
prototype over Linux 2.4 kernel using the FreeS/WAN drafts/draft-ietf-hip-dns-01.txt
IPSec and OpenSSL, and they have published their
[6] draft-ietf-hip-rvs-01, February 18, 2005, Expires:
experience in [9]. August 19, 2005, http://www.ietf.org/internet-
The paper describes problem situations in the drafts/draft-ietf-hip-rvs-01.txt
deployment of the key infrastructure due to that fact
that it is hard for any host to remember all other Hosts [7] RFC3526: More Modular Exponential (MODP) Diffie-
Identities. HIP Specification is proposing DNS to be Hellman groups for Internet Key Exchange (IKE), May
the storage place for all public keys (HIs), but still 2003, http://ietf.org/rfc/rfc3526.txt?number=3526
there is a problem in finding the destination host IP
address if only the destination HI or HIT is known by [8] Sarela, Mikko and Nikander, Pekka, Applying Host
the initiator. Also there are performance and latency Identity Protocol to Tactical Networks.
http://www.tcs.hut.fi/~id/publications/SarelaMilcom200
problems due the frequent DNS update of the mobile 4.pdf
host when it is changing its IP address. RVS server had
been proposed to solve this problem, but this idea is
home agent in mobile IP terminology and this might
not give advantage to HIP over mobile IP.

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE
[9] Henderson, Thomas R., Ahrenholz, Jeffrey M., and [12] Nikander, P, Applying host identity protocol to the
Kim, Jae H. Experience with the Host Identity Protocol Internet addressing architecture; Applications and the
for Secure Host Mobility and Multihoming, Wireless Internet, 2004. Proceedings. 2004 International
Communications and Networking, 2003. WCNC 2003. Symposium on2004 Page(s):5
2003 IEEE Volume 3, 16-20 March 2003 Page(s):2120 - [13] PKCS #3: Diffie-Hellman Key-Agreement Standard, An
2125 vol.3 RSA Laboratories Technical Note, Version 1.4, Revised
November 1, 1993 http://www.chinese-
[10] Henderson, T.R.; Host mobility for IP networks: a watercolor.com/nicholas/linux/pkcs-3.pdf
comparison, Network, IEEE Volume 17, Issue 6, Nov.-
Dec. 2003 Page(s):18 - 26 [14] Jokela, Petri, Nikander, Pekka, Melen, Jan, Ylitalo,
Jukka, and Wall, Jorma, Host Identity Protocol -
[11] Jokela, Petri, Nikander, Pekka, Melen, Jan, Ylitalo, Extended Abstract, in Proceedings of WWRF8bis
Jukka, and Wall, Jorma, Host Identity Protocol: (electronic), Beijing, China, February 26-27, 2004
Achieving Ipv4-Ipv6 handovers without tunneling. http://www.tml.hut.fi/~pnr/publications/wwrf8bis.pdf
http://users.tkk.fi/~jylitalo/publications/Evolute03-
Jokela-et-al.pdf

Proceedings of the International Conference on Networking, International Conference on Systems and


International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06)
0-7695-2552-0/06 $20.00 © 2006 IEEE