Network Working Group                                           D. Zhang
Internet-Draft                                                    Huawei
Intended status: Experimental                                   M. Komu
Expires: July 14, 2012                                  January 11, 2012


     An Extension of HIP Base Exchange to Support Identity Privacy
                 draft-zhang-hip-privacy-protection-04

Abstract

   In this document, an extension of HIP Base Exchange (BEX) is proposed
   protect the identity privacy of HIP hosts.  Apart from describing the
   protocol and packet formats, the applicability and the security
   strength of the proposed approach are analyzed.  This work is based
   on BLIND [YLI04].

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 14, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Zhang & Komu              Expires July 14, 2012                 [Page 1]


Internet-Draft                 HIP Privacy                  January 2012


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of the Protocol . . . . . . . . . . . . . . . . . . .  4
   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Base Exchange Extensions . . . . . . . . . . . . . . . . .  5
       4.1.1.  Blind Initiator and Responder  . . . . . . . . . . . .  5
       4.1.2.  Blind Initiator  . . . . . . . . . . . . . . . . . . .  6
       4.1.3.  Blind Responder  . . . . . . . . . . . . . . . . . . .  8
     4.2.  UPDATE Extensions  . . . . . . . . . . . . . . . . . . . .  8
     4.3.  CLOSE  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Control Header Flags . . . . . . . . . . . . . . . . . . .  9
   6.  Applicability Consideration  . . . . . . . . . . . . . . . . .  9
     6.1.  Opportunistic Base Exchange  . . . . . . . . . . . . . . .  9
     6.2.  Comparison of Disposable Identities vs. Blind  . . . . . . 10
     6.3.  HIP-based Middleboxes  . . . . . . . . . . . . . . . . . . 10
     6.4.  Immediate Carriage and Conveyance of Upper-layer
           Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
















Zhang & Komu              Expires July 14, 2012                 [Page 2]


Internet-Draft                 HIP Privacy                  January 2012


1.  Introduction

   The Host Identity Protocol (HIP) [RFC5201] was proposed as a complete
   solution to address multiple critical issues (e.g., mobility, multi-
   homing, and security) which the current Internet infrastructure
   suffers from.  In order to achieve this objective, HIP separates the
   semantics of host identifier from IP addresses by intercepting an
   "ID" layer in the middle of the network layer and the transport
   layer.  Compared to other ID/Locator separating solutions (e.g.,
   LISP, GSE, ILNP, etc.), HIP is security-inherent.  Each HIP host has
   a public key pair; the public key is used as the Host Identifier (HI)
   transported over the Internet while the private key is maintained
   locally.

   Additionally, a HIP host also needs to generate a 128-bits long Host
   Identity Tag (HIT) by hashing its HI.  HITs are transported in the
   common parts of HIP headers and regarded by upper layer protocols
   (e.g., TCP) as ordinary IPv6 addresses.  Before two HIP hosts
   communicate with each other, they use the HIP Base Exchange protocol
   (HIP BEX) to verify each other's identity and create shared keying
   material for subsequent communications.  Normally, the HIT and HI of
   a host are much steadier than its locator (i.e., IP address).
   Therefore, the changes in the location of a host will not be detected
   by upper layer protocols.

   In the current version of HIP BEX, the identities (i.e., HITs and
   HIs) of communicating partners are transported in plaintexts.  This
   caused an identity privacy issue.  In many scenarios, a user may want
   to keep its identity confidential to other unrelated entities.
   However, by eavesdropping HIP BEXs, it is possible for a third party
   to identify a HIP host even when the host is attached to different
   locations in the network.  As a consequence, it is easier for an
   attacker to combine the host's activities to reason additional useful
   information.

   The identity privacy issue mentioned here is closely related with the
   location privacy issues.  As illustrated in [RFC4882], the movement
   of a mobile host can be detected if any constant information related
   with the host is detected by a third party.  Such information can be
   a Security Parameter Index (SPI) in an IPsec [RFC4301] header, an
   Interface Identifier (IID) [RFC2462] in an IPv6 address that remains
   unchanged across networks, the home address of a host supporting
   mobile IP, the MAC address of a mobile host, an identifier of a
   mobile host adopted in a upper layer protocol, and so on.  Therefore,
   in order to protect the privacy of a mobile HIP host, a comprehensive
   solution which cover multiple layers must be provided, and the
   identity privacy is one of the most important issues which need to be
   considered in such a solution.  In the current HIP BEX, HIs and HITs



Zhang & Komu              Expires July 14, 2012                 [Page 3]


Internet-Draft                 HIP Privacy                  January 2012


   are the only permanent information transported in plaintext in
   different HIP BEXs.  Although SPIs are also transported in plaintext,
   the valid period of a SPI is no longer than the associated IPsec SA.
   Therefore, without tracing the permanent identity of a host, SPIs
   mean much less for attackers.

   Instead of attempting to address the overall privacy problem, the
   solution proposed in this document only addresses the identity
   privacy issue, that is, the solution provides protection against the
   attempts to track HIP hosts by inspecting the HITs and HIs
   transported in HIP BEXs.


2.  Terminology

   BEX: Base Exchange

   HIP: Host Identity Protocol

   HI: Host Identifier

   HIT: Host Identity Tag


3.  Overview of the Protocol

   The proposed solution is an extension of BLIND, a framework for
   protecting the identity privacy of hosts that are identified with
   their public keys.  In our solution, if an initiator of a HIP base
   exchange intends to protect its identity privacy, it will not
   transport its HI and HIT in plaintexts over the network.  Instead, it
   generates a scramble HIT for itself.  The scramble HIT is called a
   blinded HIT in this document.  If the initiator intends to protect
   the identity privacy of its communicating partner, it also needs to
   generate a blinded HIT for the partner as well.  A blinded HIT is
   generated by hashing the concatenation of a nonce and the associated
   HIT.


4.  Protocol Description

   In order to benefit the discussion, assume there is a HIP host called
   Initiator which intends to communicate with a HIP host called
   Responder.  The HITs of Initiator are referred to as HIT-Is, and the
   HITs of Responder are referred to as HIT-Rs.  Additionally, the
   blinded HITs of Initiator and Responder are referred to as B-HIT-Is
   and B-HIT-Rs respectively.  In the discussion of this section, it is
   assumed that Initiator has got a HIT-R through an out-of-band method



Zhang & Komu              Expires July 14, 2012                 [Page 4]


Internet-Draft                 HIP Privacy                  January 2012


   before initiating a BEX.  Otherwise, it needs to communicate with
   Responder in an opportunistic mode.  The related issues with the
   opportunistic mode are discussed in section 6.1.  Additionally, in
   this work, Initiator and Responder do not need to know each other's
   HI beforehand.  Such information will be transported in the BEX in an
   encrypted way.

4.1.  Base Exchange Extensions

   In order to distinguish the proposed approach from the ordinary BEX
   protocol, two control header bits, I and R are introduced.  In the
   HIP packet, I indicates that the HI and HIT of the initiator of an
   HIP BEX transported in the HIP header are scrambled, and R indicates
   that the HI and HIT of the responder of an HIP BEX transported in the
   HIP header are scrambled.

4.1.1.  Blind Initiator and Responder

   In the scenarios where the identity privacy of both communicating
   partners needs to be protected, Initiator needs to generate a blind
   HIT (i.e., B-HIT-I) for itself and a blind HIT (i.e., B-HIT-R) for
   Responder before initiating a BEX.

   In order to achieve this, Initiator first selects a random number
   nonce, N. Then, Initiator generates a B-HIT-I by SHA-1 hashing the
   concatenation of N and HIT-I, that is, B-HIT-I=SHA-1(N, HIT-I).  In
   the same way, Initiator generates a B-HIT-R for Responder.  B-HIT-
   R=SHA-1(N, HIT-R).

   An extended BEX handshake is illustrated in Figure 1.  In the I1
   packet transported in the step 1, the blinded HITs of Initiator and
   Responder, and the nonce, N, are transported in plaintexts.

   After receiving the I1 packet, Responder needs to calculate an SHA-1
   hash value from the concatenation of N and HIT-R, and compare it with
   the B-HIT-R transported in the I1 packet.  Note that if the Responder
   has multiple HITs, this process may need to be performed repeatedly.
   If there is no hash identical to the B-HIT-R, I1 packet will be
   discarded.  If a hash value matches the B-HIT-R, Responder sends a
   pre-generated R1 packet of the associated HI to Initiator (see step 2
   in Figure 1).  In order to avoid Deny of Service attacks, Responder
   should not maintain any state information at this step.  However, in
   practice, although it is not recommended, Responder can also select
   to maintain the mapping from the pseudonym and the associated HI in
   order to simplify the process of the I2 packet.

   If Initiator has already got the HI of Responder, it can use the HI
   to assess the validity of the signature of the R1 packet.  Otherwise,



Zhang & Komu              Expires July 14, 2012                 [Page 5]


Internet-Draft                 HIP Privacy                  January 2012


   Initiator cannot verify the signature of the R1 packet until it gains
   the HI from the R2 packet.  No matter whether Initiator can assess
   the signature, Initiator generates a symmetric key, KDH, using the
   Diffie-Hellman algorithm and adopts the key to calculate the keying
   material with the HIT-R and B-HIT-I:

   Key1=SHA1 (KDH, HIT-R, B-HIT-I, 1), ...

   Keyn=SHA1 (KDH, HIT-R, B-HIT-I, n),

   Keying material=Key1 XOR ...  XOR Keyn.

   The keying material is then used to generate a symmetric key to
   encrypt the HI of Initiator.  The encrypted information is sent to
   Responder in an I2 packet (see step 3).  Additionally, the I2 packet
   also contains the nonce which was transported in I1 and the pseudonym
   which was transported in R1.  After receiving the I2 packet,
   Responder computes a key in the same way as the Initiator.  Using the
   key, Responder decrypts the HIT and HI information of Initiator, and
   verifies the correctness of B-HIT-I.  Moreover, Responder encrypts
   its HI using the obtained symmetric key and transports the encrypted
   HI to Initiator in a R2 packet (see step 4).  After Initiator
   receives the R2 packets, it decrypts the Responder's HI.  If
   Initiator does not know the HI of Responder, Initiator can assess its
   correctness against HIT-R and then verify the validity of the R1
   packet.

   Finally, the whole BEX handshake completes successfully.  In the
   packets transported in the exchange, both R and S are set.
  +-----+                                                       +------+
  |     |         1. I1: B-HIT-I, B-HIT-R, Nonce                |      |
  |     |------------------------------------------------------>|      |
  |     | 2. R1: B-HIT-I, B-HIT-R, puzzle, DH(r), Echo-REQ, Sig.|      |
  |     |<------------------------------------------------------|      |
  |  I  |3. I2: B-HIT-I, B-HIT-R, Nonce, DH(i), Puzzle Solution,|  R   |
  |     |     SPI Encrypt { HI-I}, RESP, Signature              |      |
  |     |------------------------------------------------------>|      |
  |     |4. R2: B-HIT-I, B-HIT-R, Encrypt {HI-R},               |      |
  |     |     SPI, HMAC, Sig.                                   |      |
  |     |<------------------------------------------------------|      |
  +-----+                                                       +------+
  Figure 1. An Extended HIP Base Exchange

4.1.2.  Blind Initiator

   In the many circumstances, only the identity privacy of Initiator
   needs to be protected.  For instance, a client may want to keep its
   identity untraceable to any third party while the server which the



Zhang & Komu              Expires July 14, 2012                 [Page 6]


Internet-Draft                 HIP Privacy                  January 2012


   client tries to communicate with intends to eliminate the overhead
   introduced by encrypting its HIT and HI.  In this case, the client
   only needs to generate a blind HIT for itself before initiating a
   BEX.  The process of generating B-HIT-I is as same as what is
   illustrated in section 4.1.1.  Then Initiator sends an I1 packet to
   Responder (see step 1 in Figure 2).  The packet consists of B-HIT-I,
   the actual HIT of Responder (HIT-R), and the nonce used in generating
   B-HIT-I.  After receiving I1, Responder sends back Initiator a R1
   packet (see step 2).  The process of generating the R1 packet is
   identical to the ordinary BEX.  Upon receiving R1, Initiator verifies
   the validity of R1 and calculates the keying material in the same way
   illustrated in section 4.1.1.  In addition, Initiator encrypts its HI
   using a key derived from the keying material and transports the
   encrypted information in I2 (see step 3).  Therefore, after receiving
   I2, Responder can compute a symmetric key to verify the correctness
   of B-HIT-I.  The symmetric key is also used to calculate the HMAC of
   the R2 packet.  Therefore, by verifying the HMAC of R2, Initiator can
   prove that Responder has shared a symmetric key with it.  In this
   exchange, only the control flag I is set.

    +-----+                                                     +------+
    |     |1. I1: B-HIT-I, HIT-R, Nonce                         |      |
    |     |---------------------------------------------------->|      |
    |     |2. R1: B-HIT-I, HIT-R, puzzle, DH(r), HI-R, Echo-REQ |      |
    |     |    Sig.                                             |      |
    |     |<----------------------------------------------------|      |
    |  I  |3. I2: B-HIT-I, HIT-R, Nonce, DH(i), Puzzle Solution,|  R   |
    |     | SPI, Encrypt {HIT-I, HI-I}, HI-R, RESP, Signature   |      |
    |     |---------------------------------------------------->|      |
    |     |4. R2: B-HIT-I, HIT-R, SPI, HMAC, Sig.               |      |
    |     |<--------------------------------------------------- |      |
    +-----+                                                     +------+
    Figure 2. An Extended HIP Base Exchange

   Typically, an Initiator can decide whether to protect its identity
   privacy according to its local policy.  Before initiating a HIP
   exchange, the Initiator can also attempt to learn whether the
   responder intends to protect its identity privacy (e.g., from
   resolution systems or referrers).  However, if there is no trustable
   method for an initiator to learn the privacy protecting policies of
   its communicating partner in advance, the initiator should carry out
   BEX in the way described in section 4.1.1.  Otherwise, if the
   initiator uncovers the HIT or HI of Responder in I1, there is no
   opportunity left for the responder to decide whether to protect its
   identity privacy.  When receiving such an I1 packet, the responder
   can select to 1) drop the packet directly if it does not support the
   extended HIP BEX, 2) carry out the handshake with the initiator in
   the way illustrated in the above section if it supports the extended



Zhang & Komu              Expires July 14, 2012                 [Page 7]


Internet-Draft                 HIP Privacy                  January 2012


   HIP BEX and prefers to protect its identity privacy, or 3) send a
   notify back if it supports the extended HIP BEX and does not intend
   to protect its identity privacy.  In the third case, the notify
   packet is used to illustrate its identity privacy protecting
   policies.  In the notify packet, the responder can proactively
   disclose its HIT.  Therefore, after receiving the notify packet, the
   initiator can decide whether to restart a new HIP BEX.

4.1.3.  Blind Responder

   In the circumstance where an initiator which does not intend to
   protect its identity privacy attempts to contact another host which
   intends to protect its identity privacy, the initiator can only
   scramble the HIT of the responder and transport its own HIT in
   plaintext.

   Figure 3 illustrates such a HIP BEX between Initiator and Responder.
   In the first step, Initiator sends HIT-I, B-HIT-R, and the nonce used
   to generate B-HIT-R in R1 to Responder.  After receiving I1,
   Responder tries to find out the associated HI using the method
   indicated in section 4.1.1.  If the HI is found, Responder then sends
   a pre-generated R1 packet of the associated HI back to Initiator (see
   step 2).  In R1, B-HIT-R is encapsulated.  After calculating the
   puzzle, Initiator sends an I2 packet back to Responder (see step 3).
   In step 4, responder sends its HI in the encapsulated part of R2
   packet to Initiator.

    +-----+                                                     +------+
    |     |1. I1: HIT-I, B-HIT-R, Nonce                         |      |
    |     |---------------------------------------------------->|      |
    |     |2. R1: HIT-I, B-HIT-R, puzzle, DH(r), Echo-REQ       |      |
    |     |    Sig.                                             |      |
    |     |<----------------------------------------------------|      |
    |  I  |3. I2: HIT-I, B-HIT-R, Nonce, DH(i), Puzzle Solution,|  R   |
    |     | SPI, HI-I, RESP, Signature                          |      |
    |     |---------------------------------------------------->|      |
    |     |4. R2: HIT-I, B-HIT-R, Encrypt {HI-R}, SPI, HMAC,    |      |
    |     |    Sig.                                             |      |
    |     |<--------------------------------------------------- |      |
    +-----+                                                     +------+
    Figure 3. An Extended HIP Base Exchange

4.2.  UPDATE Extensions

   After two hosts achieve a HIP BEX, they may also need to change their
   SPIs or HITs for certain reasons.  Such information can be
   transported in update packets.  Because the confidentiality of SPIs
   and HITs needs to be protected, such information should be



Zhang & Komu              Expires July 14, 2012                 [Page 8]


Internet-Draft                 HIP Privacy                  January 2012


   transported in an encrypted way.

   Additionally, according to different security requirement, the hosts
   changing its IP address also needs to select a new nonce to generate
   new scramble HIT(s).  The nonce and scrambled are used in the HIP
   header.  The associated flags are set as well.  For instance, if the
   identity privacy of both communicating parties needs to be protected,
   a new pair of scramble HITs need to be generated.  The new pair of
   scrambled HITs and the nonce are transported within the packet
   header.  After receiving the packet, the receiver needs to first find
   out the associate private HITs and then locate the proper keys to
   verify the signature and decrypt the SPIs.

4.3.  CLOSE

   When an existing HIP association is no longer needed, it can be
   closed using closing mechanism defined in [RFC5201].


5.  Packet Formats

5.1.  Control Header Flags

   In order to distinguish the packets in extended BEX from those in
   ordinary BEX, two control header flags are defined here:
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | | | | | | | | | | | | | |I|R| |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: if this bit is set to 1, the initiator's HIT transported in the
   packet is scrambled, and the HI in this packet is encrypted.
   Otherwise, the initiator's HIT and HI are transported within the
   common part of the packet header in an unencrypted way.

   R: if this bit is set to 1, the responder's HIT transported in the
   packet is scrambled, and the HI in this packet is encrypted.
   Otherwise, the responder's HIT and HI are transported without
   encryption.  Note that in opportunistic mode, this flag in an I1
   packet only indicate the initiator support scrambled HITs.


6.  Applicability Consideration

6.1.  Opportunistic Base Exchange

   When an Initiator does not know the HIT of its communicating partner
   beforehand, it can try to initiate the handshaking in the
   opportunistic mode.



Zhang & Komu              Expires July 14, 2012                 [Page 9]


Internet-Draft                 HIP Privacy                  January 2012


   If the initiator intends to protect its identity privacy, it can send
   its blind HIT and the associated nonce in an I1 packet to the
   responder.  Both the I and R flag in the I1 packet are set.  If the
   responder would like to protect its identity privacy, it can use the
   nonce to generate a blind HIT and send it back in a R1 packet.  The
   operations of both communicating partner in the rest of the
   handshaking is identical to what is described in section 4.1.1.  If
   the initiator does not want to protect its identity privacy, it can
   send its plain HIT in an I1 packet to the responder.  The R flag in
   the I1 packet can be set to indicate that the initiator supports
   scrambled HITs.  If the responder would like to protect its identity
   privacy, it can choose a nonce and use it to generate a blind HIT for
   itself.  Both the blind HIT and the nonce are sent back in a R1
   packet.  The operations of both communicating partner in the rest of
   the handshaking is identical to what is described in section 4.1.3.

   In the both cases above, if the responder supports scrambled HITs but
   does not want to protect its identity privacy, it can just send its
   plain HIT in the R1 packet and unset the R flag.

6.2.  Comparison of Disposable Identities vs. Blind

   During the design of the proposed approach, the solutions using
   ephemeral identities are also considered.  A host can attempt to
   prevent itself from being tracked by using different HIs in different
   BEXs.  However, some upper layer server applications may use HIs or
   HITs to identify hosts.  When a host uses ephemeral HI, it may be
   difficult for the applications to find proper state to provide
   service correctly.

   Additionally, it is difficult for a responder to use ephemeral HI to
   protect its identity, as the initiator normally need to know the
   responder's HIT to initiate a HIP BEX.

6.3.  HIP-based Middleboxes

   Currently, there is only a type of middlebox (RVS) specified in the
   HIP architecture.  Our solution introduces additional overheads to a
   RVS but will not damage its functionality.  When a RVS received an I1
   packet containing a blind HIT of the responder, the RVS has to use
   the nonce to find out the associated HIT.  Considering the large
   number of the HITs that a RVS may hold, an Initiator can select to
   disclose some bites of the plain HIT of the responder to reduce the
   overhead imposed on the RVS.







Zhang & Komu              Expires July 14, 2012                [Page 10]


Internet-Draft                 HIP Privacy                  January 2012


6.4.  Immediate Carriage and Conveyance of Upper-layer Protocol

   If a host receives a hiccups based packet, it must respond with an R1
   as described in [I-D.nikander-hip-hiccups].


7.  Security Considerations

   Our solution should be a component of a multi-layer privacy
   protection solution.  Although the confidentiality of consistent
   information transported in higher layer protocol can be protected by
   the key derived from HIP BEX, one still have to carefully avoid the
   consistent information transported below HIP layer to be disclosed to
   adversaries.  For instance, an attacker may identify the FQDN of a
   host by querying the reverse DNS system with the IP address of the
   host.

   In addition, our privacy extension may be incompatible with HIP based
   firewalls [RFC5207], relay servers [RFC5770], and other
   authentication service provided by middle boxes
   [I-D.heer-hip-middle-auth].


8.  Contributors

   This work is based on the research of Jukka Ylitalo.


9.  Acknowledgements


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4882]  Koodli, R., "IP Address Location Privacy and Mobile IPv6:
              Problem Statement", RFC 4882, May 2007.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,



Zhang & Komu              Expires July 14, 2012                [Page 11]


Internet-Draft                 HIP Privacy                  January 2012


              "Host Identity Protocol", RFC 5201, April 2008.

10.2.  Informative References

   [I-D.heer-hip-middle-auth]
              Hummen, R., Heer, T., and M. Komu, "End-Host
              Authentication for HIP Middleboxes",
              draft-heer-hip-middle-auth-04 (work in progress),
              October 2011.

   [I-D.nikander-hip-hiccups]
              Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
              Identity Protocol) Immediate Carriage and Conveyance of
              Upper- layer Protocol Signaling (HICCUPS)",
              draft-nikander-hip-hiccups-04 (work in progress),
              August 2009.

   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol (HIP)
              Communication", RFC 5207, April 2008.

   [RFC5770]  Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
              Keranen, "Basic Host Identity Protocol (HIP) Extensions
              for Traversal of Network Address Translators", RFC 5770,
              April 2010.

   [YLI04]    Ylitalo, J., "LIND: A Complete Identity Protection
              Framework for End-points", April 2004.


Authors' Addresses

   Dacheng Zhang
   Huawei

   Email: zhangdacheng@huawei.com


   Miika Komu
   Laboratory of Software Technology
   Department of Computer Science and Engineering, Aalto University
   Finland

   Email: miika@iki.fi







Zhang & Komu              Expires July 14, 2012                [Page 12]