Network Working Group Sheng Jiang Internet Draft Huawei Technologies Co., Ltd Intended status: Informational May 11, 2009 Expires: November 08, 2009 Hierarchical Host Identity Tag Architecture draft-jiang-hiprg-hhit-arch-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 5, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Jiang Expires November 08, 2009 [Page 1] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 Abstract This document analyzes the problems and limitation of the current flat-structured Host Identity Tag architecture. The document specifies a hierarchical HIT architecture which is compatible with the flat-structured HIT architecture. This architecture and the process of HIT generation ensure the global uniqueness of HITs. This architecture also enables the multiple Host Identity Protocol management 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 FQDN. 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..........................................6 4. Generating a hierarchical HIT................................7 5. Requirements for modification on HIP.........................7 6. Acknowledgements............................................8 7. Security Considerations......................................8 8. IANA Considerations.........................................8 9. References..................................................8 9.1. Normative References....................................8 9.2. Informative References..................................8 Author's Addresses.............................................9 Jiang Expires November 08, 2009 [Page 2] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 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 management domain tag and a host tag. 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 management 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." [RFC4423] 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 Expires November 08, 2009 [Page 3] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 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. For each single lookup operation, one may search through most of the database. It is unfeasible for both computing power and time reasons. 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 management domain tag 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 management domain is responsible only for a part of Jiang Expires November 08, 2009 [Page 4] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 the global HIT architecture. However, it is useful that the new 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: 32-bit HIP management domain tag and 96-bit host tag. It can represent maximum 2^32 management domains and 2^96 hosts within each management domain. | 32 bits | 96 bits | +-------------------------------+---------------------------------+ | HIP management domain tag | host tag | +-------------------------------+---------------------------------+ For the secure consideration, we assign more bits to the host tag, which is a hash result, leaving less but enough bits for HIP management domain tag. The more the number of bits the host tag 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^96) in order to find a host identity that matches with a given host tag. It should be noted that this draft does not take into account the ORCHID prefix defined in [RFC4843]. It is because the /28 bit orchid prefix with 32-bit hierarchical HIP management domain tag would leave only 68 bits or even less for host tag part, which reduce the security properties too low and increase collusion possibility too high. The HIP management 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 management domain, all the nodes should have the same HIP management domain tag or the same leftmost certain bits. Furthermore, the authority may be organized internally hierarchically. The HIP management domain tag should be assigned by a global management organization with the principle that every HIP management domain tag must be globally unique. Jiang Expires November 08, 2009 [Page 5] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 Consequentially, the HIP management domain tags may be organized hierarchically. For example, a big organization may obtain a block of HIP management tags with an assigned 24-bit prefix. It then can assign 32-bit HIP management domain tags to its sub-organizations. All these sub-organizations have the same leftmost 24-bit. The host tags remain the original meaning of HIT -"a hashed encoding of the Host Identity". For each HIP management domain, it is mandatory to maintain the uniqueness of all host tags. It is guaranteed by the process of generating a HIT, see Section 5. For resolution purposes, HITs are aggregatable with management domain tags 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. The flat HITs can be defined as a specific sub-set of the hierarchical HITs architecture. With the same reserved Flat HIT Tag (2 or 3 bits) at the beginning and the number of bits that can be chosen arbitrarily reduce 2 or 3 bits out of 128, 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 structure: | 128 bits | +-----------------------------------------------------------------+ | host identity tag | +-----------------------------------------------------------------+ Jiang Expires November 08, 2009 [Page 6] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 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: a 32-bit HIP management domain tag, a 2-bit collusion count, 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 management domain tag, the collusion count, and the host identity. Execute the SHA-1 algorithm on the concatenation. Take the 94 leftmost bits of the SHA-1 hash value. 3. Concatenate from left to right the 32-bit HIP management domain tag, the 2-bit collusion count and 94-bit hash output to form a 128-bit HIT. 4. Perform duplicate detection within the HIP management 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 management domain tag 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 management domain. The design reduces the number of bit of hash output from 96 to 94. It does reduce the safety. However, O(2^94) 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. Jiang Expires November 08, 2009 [Page 7] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 6. Acknowledgements Useful comments were made by Miika Komu from HIIT, and other members of the IRTF HIPRG research group. 7. 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 94-bit long, it does not affect the self certifying security property. 8. IANA Considerations This document defines a new namespace: HIP management domain tag. It is a 32-bit long value, which represents a globally unique HIP management domain. IANA may found an authority institute to manage the global assignment of HIP management domain tag. 9. References 9.1. Normative References [RFC4423] R. Moskowitz, P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC4423, 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 2007. Jiang Expires November 08, 2009 [Page 8] Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009 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 Phone: 86-10-82836774 Email: shengjiang@huawei.com Jiang Expires November 08, 2009 [Page 9]