[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                        S. Jiang
Internet Draft                                                  X. Xu
Intended status: Informational                               D. Zhang
Expires: November 5, 2010                 Huawei Technologies Co., Ltd
                                                              T. Chen
                                                          May 5, 2010

              Hierarchical Host Identity Tag Architecture

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 November 5, 2010.

Copyright Notice

   Copyright (c) 2010 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
   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.

Jiang, et al.         Expires November 5, 2010                [Page 1]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010


   The current flat-structured Host Identity Tag architecture has
   various problems and limitation. Hence, a hierarchical HIT
   architecture that is compatible with the flat-structured HIT
   architecture is introduced in the document. This architecture and the
   process of HIT generation ensure the global uniqueness of HITs. This
   architecture also enables the multiple Host Identity Protocol
   administrative domains, solves the deployment problem of current
   flat-structured HIT architecture. It also enhances the scalability
   and resolution efficiency of the mapping system from HIT to IP or

Table of Contents

   1. Introduction................................................3
   2. Analysis of the Current Flat-structured HIT Architecture......3
   3. Hierarchical HIT Architecture................................5
      3.1. Compatible flat-structured HITs.........................6
      3.2. HITs on nodes..........................................7
   4. Generating a hierarchical HIT................................7
   5. Requirements for modification on HIP.........................8
   6. Security Considerations......................................8
   7. IANA Considerations.........................................8
   8. Acknowledgements............................................8
   9. References..................................................9
      9.1. Normative References....................................9
      9.2. Informative References..................................9
   Author's Addresses............................................10

Jiang, et al.         Expires November 5, 2010                [Page 2]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

1. Introduction

   This document analyzes the problems and limitation of the current
   flat-structured Host Identity Tag (HIT, [RFC4423]) architecture in
   the Host Identity Protocol (HIP, [RFC5201]). The document specifies a
   hierarchical HIT architecture, which splits a HIT into two parts: a
   HIP Administrative Domain (AD) ID and a local host ID. The proposed
   hierarchical HIT architecture is also compatible with the flat-
   structured HIT architecture. The format of HIT and the detail process
   of HIT generation are defined. This architecture and the process of
   HIT generation ensure the global uniqueness of HITs. This
   architecture also enables the multiple HIP administrative domains,
   solves the deployment problem of current flat-structured HIT
   architecture. The aggregation of HITs in this architecture also
   enhances the scalability and resolution efficiency of the mapping
   system from HIT to IP or FQDN.

2. Analysis of the Current Flat-structured HIT Architecture

   The HIT concept was defined in [RFC5201]: "... the Host Identity Tag
   (HIT), becomes the operational representation. It is 128 bits long
   and is used in the HIP payloads and to index the corresponding state
   in the end hosts."

   In order to be able to represent hosts, the uniqueness of HITs is
   required in global scope. "In the HIP packets, the HITs identify the
   sender and recipient of a packet. Consequently, a HIT should be
   unique in the whole IP universe as long as it is being used."

   Although mathematically "the probability of HIT collision between two
   hosts is very low" [RFC5201], there is no mechanism to ensure that a
   HIT is global unique.

   The current defined HIT is generated according to the ORCHID
   generation method described in [RFC4843]: "several possible
   methods ... to preserve a low enough probability of collisions".
   However, it cannot guarantee the global uniqueness of HITs.
   Furthermore, while the number of end devices continuously grows in
   the future, the possibility of HIT collision will increase rapidly. A
   technical mechanism is needed to ensure the global uniqueness of
   HITs, particularly with the consideration that collisions may happen.
   When such collision happens, more than one hosts will have the same
   HIT. Then, the HIT cannot uniquely identify a certain host.

Jiang, et al.         Expires November 5, 2010                [Page 3]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

   Although there is a rough solution for how to distinguish duplicated
   HITs, it is far from a feasible or best solution.

   [RFC4423] states "In the extremely rare case of a single HIT mapping
   to more than one Host Identity, the Host Identifiers (public keys)
   will make the final difference." It means the mapping system between
   HIP and IP must store or at least be aware of the Host Identifiers of
   all hosts. Given the facts that the Host Identifiers are quite large
   and may be in various lengths, the storage and management burden of
   the mapping system could be quite high. If there was a mechanism to
   ensure the global uniqueness of HITs, then, the mapping system would
   not have to be aware the Host Identifiers.

   Furthermore, within the flat-structured HIT architecture, the
   robustness of resolution efficiency in the supporting mapping system
   is in a big question mark: a mapping server has to hold or at least
   to be able to access a large database that contains information on
   all HITs in the global scope. There more than a billion hosts now on
   the Internet and a global deployment of HIP would require an equal
   amount of HITs. In the future, there could be even billions of
   machines or even higher. The storage burden, maintenance consumption
   and synchronization updating are problems that are very difficult to
   solve. If the HITs were organized hierarchically, the mapping system
   could easily be organized hierarchically, even distributed.

   One more disadvantage that the flat-structured HIT architecture is
   the difficulties for management. There is nothing common between HITs
   that were assigned by the same authority or that their represented
   hosts have the same properties. Hence, it is difficult to categorize
   HITs. Although this provides privacy to the end-hosts, the Access
   Control Lists (ACLs) would have to have a full list of HITs
   accessible to permitted services. Contrarily, the hierarchical HITs
   are more aggregatable. It makes HITs manageable. HITs can be grouped
   according to its belonging authority or domain. Each network operator
   just needs to manage and maintain HITs and their mapping information
   in a relatively small range.

   According to the above analysis, it is natural to turn the flat HIT
   architecture into hierarchy. It can effectively reduce the global
   uniqueness requirement into much smaller scope uniqueness
   requirement. In another word, if a hierarchical HIT with a global
   unique AD ID is locally unique, it is guaranteed to be global
   unique. It can improve the resolution processing and enhance the
   scalability and resolution efficiency. Furthermore, it can optimize
   the management of both the host identity and the mapping database.
   Each administrative domain is responsible only for a part of the
   global HIT architecture. However, it is useful that the new

Jiang, et al.         Expires November 5, 2010                [Page 4]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

   hierarchical HIT architecture is compatible with the flat HIT
   architecture for privacy purposes and other usage scenarios.

3. Hierarchical HIT Architecture

   In this document, we introduce a two-level hierarchically structured
   HIT architecture. HIT is "128 bits long value and is used in the HIP
   payloads and to index the corresponding state in the end hosts."
   [RFC5201] "In the HIP packets, the HITs identify the sender and
   recipient of a packet." [RFC4423] HITs refer to nodes or virtual
   nodes. All nodes are required to have at least one HIT. A single node
   may also have multiple HITs. Applications on a same node may bind to
   different HITs.

   In the hierarchical HIT namespace, a 128-bit HIT consists of two
   parts: an n-bit HIP AD ID and a (128-n)-bit local host ID. (n is a
   subject to be decided in the future.) It can represent maximum 2^n
   administrative domains and 2^(128-n) hosts within each administrative
   domain. The Administrative Domain ID has embedded organizational
   affiliation and global uniqueness. The local host ID is a hash over
   the AD ID and the public key of the ID owner.

   |           n bits              |            128-n bits           |
   |  HIP Administrative Domain ID |           local host ID         |

   For the secure consideration, we recommend to assign more bits to the
   local host ID, which is a hash result, leaving less but enough bits
   for HIP Administrative Domain ID. The more the number of bits the
   local host ID is, the more secure it is against brute-force attacks.
   In the worst case, if the hash algorithm cannot be inverted, the
   expected number of iterations required for a brute force attack is
   O(2^(128-n)) in order to find a host identity that matches with a
   given local host ID. It should be noted that this draft does not take
   into account the ORCHID prefix defined in [RFC4843] for two reasons:
   firstly, ORCHID is only temporary assigned for experimental usage
   till 2014 only. The proposal design in the document is targeting to
   be used continuously after 2014. Secondly, the fixed 28-bit orchid
   prefix reduces the security properties massively and increase
   collusion possibility highly.

   The HIP administrative domain, as its literal, is a logic region in
   which the HIs of all nodes are assigned by the same authority. Within
   a same HIP administrative domain, all the nodes should have the same
   HIP AD ID or the same leftmost certain bits. Furthermore, the
   authority may be organized internally hierarchically.

Jiang, et al.         Expires November 5, 2010                [Page 5]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

   The HIP AD ID should be assigned by a global administrative
   organization with the principle that every HIP AD ID must be globally

   Consequentially, the HIP AD IDs may be organized hierarchically. For
   example, a big organization may obtain a block of HIP AD IDs with an
   assigned 16-bit prefix. It then can assign 24-bit HIP AD IDs to its
   sub-organizations. All these sub-organizations have the same leftmost

   One promising allocation solution of HIP AD ID is following current
   routable IP address allocation system [RFC2050]. At first IANA
   allocates some HIP AD ID prefixes to RIR (Region Internet Registry)
   or NIR (National Internet Registry),then RIR or NIR sub-allocates the
   HIP AD ID prefix to LIR or backbone ISP that subdivides the tag
   prefix to middle or small ISP. Historical experience of routable IP
   address allocation indicates that the allocation system can ensure
   global uniqueness of HIP AD IDs.

   One advantage of this solution is that the HHIT architecture can
   build distributed catalogue based on current IP address Internet
   Registry. Each level Internet Registry only needs to maintain its
   HHIT information. This catalogue is like current IP Whois Server
   operated by each IP address Internet Registry. But it should include
   many more attributes about a HHIT, such as organizational
   affiliation, geographical information, privacy protection rule etc.
   The catalogue should be independent of current IP Whois system and IP
   address Internet Registry should provide some mechanism to translate
   HHIT to its useful attributes on demand of various applications.

   The local host IDs remains the original meaning of HIT - "a hashed
   encoding of the Host Identity". For each HIP administrative domain,
   it is mandatory to maintain the uniqueness of all local host IDs. It
   is guaranteed by the process of generating a HIT, see Section 5.

   For resolution purposes, HITs are aggregatable with AD IDs of
   arbitrary bit-length, similar to IPv4 addresses under Classless
   Inter-Domain Routing [RFC4632].

3.1. Compatible flat-structured HITs

   Obviously, not all hosts are willing to use hierarchical HITs in all
   scenarios for various reasons, such as privacy. Therefore, it is
   useful that the hierarchical HIT architecture keep compatible with
   the flat HIT architecture.

Jiang, et al.         Expires November 5, 2010                [Page 6]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

   The flat HITs can be defined as a specific sub-set of the
   hierarchical HITs architecture. With the same reserved Flat HIT Tag
   (3 or 4 bits) at the beginning, for example, the left-most 3 bits is
   000, the flat HITs can be used as defined in [RFC4423].

   |                           128 bits                              |
   |FHIT Tag|            Flat host identity tag                      |

3.2. HITs on nodes

   HIP-enabled nodes may have considerable or little knowledge of the
   internal structure of hierarchical HITs, depending on the role the
   node plays (for instance, host versus mapping server). At a
   minimum, a node may consider pre-generated HITs have no internal

   |                           128 bits                              |
   |                       host identity tag                         |

   Only sophisticated hosts may additionally be aware of the type of
   their HITS and use the hierarchical structure of HITs to simplify the
   resolution procedure.

4. Generating a hierarchical HIT

   The process of generating a new hierarchical HIT takes three input
   values: an n-bit HIP AD ID, a 2-bit collusion count, (an example, it
   is a subject to be changed in the future.) the host identity (the
   public key of an asymmetric key pair). A hierarchical HIT should be
   generated as follows:

      1. Set the 2-bit collision count to zero.

      2. Concatenate from left to right the HIP AD ID, the collusion
         count, and the host identity. Execute the SHA-1 algorithm on
         the concatenation. Take the (128-2-n) leftmost bits of the
         SHA-1 hash value.

      3. Concatenate from left to right the n-bit HIP AD ID, the 2-bit
         collusion count and (128-2-n)-bit hash output to form a 128-
         bit HIT.

Jiang, et al.         Expires November 5, 2010                [Page 7]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

      4. Perform duplicate detection within the HIP administrative
         domain scope. If a HIT collision is detected, increment the
         collision count by one and go back to step 2. However, after
         four collisions, stop and report the error. (Note: the
         duplicate detection mechanism is not discussed in this
         document. It may be broadcast or central registration.)

   The design that includes the HIP AD ID in the hash input is mainly
   against the re-computation attack: create a database of HITs and
   matching public keys. With the design, an attacker must create a
   separate database for each HIP administrative domain.

   The design reduces the number of bit of hash output 2 bits lower. It
   does reduce the safety. However, O(2^(128-2-n)) iterations is large
   enough to prevent brute-force attacks.

   For security reason, the abovementioned SHA-1 hash algorithm may be
   replaced by any safer algorithm.

5. Requirements for modification on HIP

   The usage of hierarchical HITs requires either a new version of HIP
   protocol or a new critical flag in the header of HIP control
   packets. The latter is considered easier and more fulfill.

6. Security Considerations

   The most important security property of HIT is that it is self-
   certifying (i.e., given a HIT, it is computationally hard to find a
   Host Identity key that matches the HIT). Although this document
   limits the hash output to be (128-2-n)-bit long, it does not affect
   the self certifying security property.

7. IANA Considerations

   This document defines a new namespace: HIP AD ID. It is an n-bit long
   value, which represents a globally unique HIP administrative domain.
   IANA may found an authority institute to manage the global assignment
   of HIP AD ID.

8. Acknowledgements

   Useful comments were made by Miika Komu from HIIT, and other members
   of the IRTF HIPRG research group.

Jiang, et al.         Expires November 5, 2010                [Page 8]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

9. References

9.1. Normative References

   [RFC2050] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg and J.
             Postel "Internet Registry IP Allocation Guidelines", RFC
             2050, November 1996

   [RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol (HIP)
             Architecture", RFC 4423, May 2006.

   [RFC5201] R. Moskowitz, et al., "Host Identity Protocol", RFC 5201,
             Oct 2007.

9.2. Informative References

   [RFC4632] V. Fuller, T. Li, "Classless Inter-Domain Routing (CIDR):
             The Internet Address Assignment and Aggregation Plan",
             RFC4632, August 2006.

   [RFC4843] P. Nikander, et al., "An IPv6 Prefix for Overlay Routable
             Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April

Jiang, et al.         Expires November 5, 2010                [Page 9]

Internet-Draft   draft-jiang-hiprg-hhit-arch-04.txt           May 2010

Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: shengjiang@huawei.com

   Xiaohu Xu
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: xuxiaohu@huawei.com

   Dacheng Zhang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: zhangdacheng@huawei.com

   Tao Chen
   No. 4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   Email: chentao@cnnic.cn

Jiang, et al.         Expires November 5, 2010               [Page 10]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/