idnits 2.17.1 draft-jiang-hiprg-hhit-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 2010) is 5104 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft X. Xu 3 Intended status: Informational D. Zhang 4 Expires: November 5, 2010 Huawei Technologies Co., Ltd 5 T. Chen 6 CNNIC 7 May 5, 2010 9 Hierarchical Host Identity Tag Architecture 10 draft-jiang-hiprg-hhit-arch-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute working 19 documents as Internet-Drafts. The list of current Internet-Drafts is 20 at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on November 5, 2010. 29 Copyright Notice 31 Copyright (c) 2010 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Abstract 46 The current flat-structured Host Identity Tag architecture has 47 various problems and limitation. Hence, a hierarchical HIT 48 architecture that is compatible with the flat-structured HIT 49 architecture is introduced in the document. This architecture and the 50 process of HIT generation ensure the global uniqueness of HITs. This 51 architecture also enables the multiple Host Identity Protocol 52 administrative domains, solves the deployment problem of current 53 flat-structured HIT architecture. It also enhances the scalability 54 and resolution efficiency of the mapping system from HIT to IP or 55 FQDN. 57 Table of Contents 59 1. Introduction................................................3 60 2. Analysis of the Current Flat-structured HIT Architecture......3 61 3. Hierarchical HIT Architecture................................5 62 3.1. Compatible flat-structured HITs.........................6 63 3.2. HITs on nodes..........................................7 64 4. Generating a hierarchical HIT................................7 65 5. Requirements for modification on HIP.........................8 66 6. Security Considerations......................................8 67 7. IANA Considerations.........................................8 68 8. Acknowledgements............................................8 69 9. References..................................................9 70 9.1. Normative References....................................9 71 9.2. Informative References..................................9 72 Author's Addresses............................................10 74 1. Introduction 76 This document analyzes the problems and limitation of the current 77 flat-structured Host Identity Tag (HIT, [RFC4423]) architecture in 78 the Host Identity Protocol (HIP, [RFC5201]). The document specifies a 79 hierarchical HIT architecture, which splits a HIT into two parts: a 80 HIP Administrative Domain (AD) ID and a local host ID. The proposed 81 hierarchical HIT architecture is also compatible with the flat- 82 structured HIT architecture. The format of HIT and the detail process 83 of HIT generation are defined. This architecture and the process of 84 HIT generation ensure the global uniqueness of HITs. This 85 architecture also enables the multiple HIP administrative domains, 86 solves the deployment problem of current flat-structured HIT 87 architecture. The aggregation of HITs in this architecture also 88 enhances the scalability and resolution efficiency of the mapping 89 system from HIT to IP or FQDN. 91 2. Analysis of the Current Flat-structured HIT Architecture 93 The HIT concept was defined in [RFC5201]: "... the Host Identity Tag 94 (HIT), becomes the operational representation. It is 128 bits long 95 and is used in the HIP payloads and to index the corresponding state 96 in the end hosts." 98 In order to be able to represent hosts, the uniqueness of HITs is 99 required in global scope. "In the HIP packets, the HITs identify the 100 sender and recipient of a packet. Consequently, a HIT should be 101 unique in the whole IP universe as long as it is being used." 102 [RFC4423] 104 Although mathematically "the probability of HIT collision between two 105 hosts is very low" [RFC5201], there is no mechanism to ensure that a 106 HIT is global unique. 108 The current defined HIT is generated according to the ORCHID 109 generation method described in [RFC4843]: "several possible 110 methods ... to preserve a low enough probability of collisions". 111 However, it cannot guarantee the global uniqueness of HITs. 112 Furthermore, while the number of end devices continuously grows in 113 the future, the possibility of HIT collision will increase rapidly. A 114 technical mechanism is needed to ensure the global uniqueness of 115 HITs, particularly with the consideration that collisions may happen. 116 When such collision happens, more than one hosts will have the same 117 HIT. Then, the HIT cannot uniquely identify a certain host. 119 Although there is a rough solution for how to distinguish duplicated 120 HITs, it is far from a feasible or best solution. 122 [RFC4423] states "In the extremely rare case of a single HIT mapping 123 to more than one Host Identity, the Host Identifiers (public keys) 124 will make the final difference." It means the mapping system between 125 HIP and IP must store or at least be aware of the Host Identifiers of 126 all hosts. Given the facts that the Host Identifiers are quite large 127 and may be in various lengths, the storage and management burden of 128 the mapping system could be quite high. If there was a mechanism to 129 ensure the global uniqueness of HITs, then, the mapping system would 130 not have to be aware the Host Identifiers. 132 Furthermore, within the flat-structured HIT architecture, the 133 robustness of resolution efficiency in the supporting mapping system 134 is in a big question mark: a mapping server has to hold or at least 135 to be able to access a large database that contains information on 136 all HITs in the global scope. There more than a billion hosts now on 137 the Internet and a global deployment of HIP would require an equal 138 amount of HITs. In the future, there could be even billions of 139 machines or even higher. The storage burden, maintenance consumption 140 and synchronization updating are problems that are very difficult to 141 solve. If the HITs were organized hierarchically, the mapping system 142 could easily be organized hierarchically, even distributed. 144 One more disadvantage that the flat-structured HIT architecture is 145 the difficulties for management. There is nothing common between HITs 146 that were assigned by the same authority or that their represented 147 hosts have the same properties. Hence, it is difficult to categorize 148 HITs. Although this provides privacy to the end-hosts, the Access 149 Control Lists (ACLs) would have to have a full list of HITs 150 accessible to permitted services. Contrarily, the hierarchical HITs 151 are more aggregatable. It makes HITs manageable. HITs can be grouped 152 according to its belonging authority or domain. Each network operator 153 just needs to manage and maintain HITs and their mapping information 154 in a relatively small range. 156 According to the above analysis, it is natural to turn the flat HIT 157 architecture into hierarchy. It can effectively reduce the global 158 uniqueness requirement into much smaller scope uniqueness 159 requirement. In another word, if a hierarchical HIT with a global 160 unique AD ID is locally unique, it is guaranteed to be global 161 unique. It can improve the resolution processing and enhance the 162 scalability and resolution efficiency. Furthermore, it can optimize 163 the management of both the host identity and the mapping database. 164 Each administrative domain is responsible only for a part of the 165 global HIT architecture. However, it is useful that the new 166 hierarchical HIT architecture is compatible with the flat HIT 167 architecture for privacy purposes and other usage scenarios. 169 3. Hierarchical HIT Architecture 171 In this document, we introduce a two-level hierarchically structured 172 HIT architecture. HIT is "128 bits long value and is used in the HIP 173 payloads and to index the corresponding state in the end hosts." 174 [RFC5201] "In the HIP packets, the HITs identify the sender and 175 recipient of a packet." [RFC4423] HITs refer to nodes or virtual 176 nodes. All nodes are required to have at least one HIT. A single node 177 may also have multiple HITs. Applications on a same node may bind to 178 different HITs. 180 In the hierarchical HIT namespace, a 128-bit HIT consists of two 181 parts: an n-bit HIP AD ID and a (128-n)-bit local host ID. (n is a 182 subject to be decided in the future.) It can represent maximum 2^n 183 administrative domains and 2^(128-n) hosts within each administrative 184 domain. The Administrative Domain ID has embedded organizational 185 affiliation and global uniqueness. The local host ID is a hash over 186 the AD ID and the public key of the ID owner. 188 | n bits | 128-n bits | 189 +-------------------------------+---------------------------------+ 190 | HIP Administrative Domain ID | local host ID | 191 +-------------------------------+---------------------------------+ 193 For the secure consideration, we recommend to assign more bits to the 194 local host ID, which is a hash result, leaving less but enough bits 195 for HIP Administrative Domain ID. The more the number of bits the 196 local host ID is, the more secure it is against brute-force attacks. 197 In the worst case, if the hash algorithm cannot be inverted, the 198 expected number of iterations required for a brute force attack is 199 O(2^(128-n)) in order to find a host identity that matches with a 200 given local host ID. It should be noted that this draft does not take 201 into account the ORCHID prefix defined in [RFC4843] for two reasons: 202 firstly, ORCHID is only temporary assigned for experimental usage 203 till 2014 only. The proposal design in the document is targeting to 204 be used continuously after 2014. Secondly, the fixed 28-bit orchid 205 prefix reduces the security properties massively and increase 206 collusion possibility highly. 208 The HIP administrative domain, as its literal, is a logic region in 209 which the HIs of all nodes are assigned by the same authority. Within 210 a same HIP administrative domain, all the nodes should have the same 211 HIP AD ID or the same leftmost certain bits. Furthermore, the 212 authority may be organized internally hierarchically. 214 The HIP AD ID should be assigned by a global administrative 215 organization with the principle that every HIP AD ID must be globally 216 unique. 218 Consequentially, the HIP AD IDs may be organized hierarchically. For 219 example, a big organization may obtain a block of HIP AD IDs with an 220 assigned 16-bit prefix. It then can assign 24-bit HIP AD IDs to its 221 sub-organizations. All these sub-organizations have the same leftmost 222 16-bit. 224 One promising allocation solution of HIP AD ID is following current 225 routable IP address allocation system [RFC2050]. At first IANA 226 allocates some HIP AD ID prefixes to RIR (Region Internet Registry) 227 or NIR (National Internet Registry),then RIR or NIR sub-allocates the 228 HIP AD ID prefix to LIR or backbone ISP that subdivides the tag 229 prefix to middle or small ISP. Historical experience of routable IP 230 address allocation indicates that the allocation system can ensure 231 global uniqueness of HIP AD IDs. 233 One advantage of this solution is that the HHIT architecture can 234 build distributed catalogue based on current IP address Internet 235 Registry. Each level Internet Registry only needs to maintain its 236 HHIT information. This catalogue is like current IP Whois Server 237 operated by each IP address Internet Registry. But it should include 238 many more attributes about a HHIT, such as organizational 239 affiliation, geographical information, privacy protection rule etc. 240 The catalogue should be independent of current IP Whois system and IP 241 address Internet Registry should provide some mechanism to translate 242 HHIT to its useful attributes on demand of various applications. 244 The local host IDs remains the original meaning of HIT - "a hashed 245 encoding of the Host Identity". For each HIP administrative domain, 246 it is mandatory to maintain the uniqueness of all local host IDs. It 247 is guaranteed by the process of generating a HIT, see Section 5. 249 For resolution purposes, HITs are aggregatable with AD IDs of 250 arbitrary bit-length, similar to IPv4 addresses under Classless 251 Inter-Domain Routing [RFC4632]. 253 3.1. Compatible flat-structured HITs 255 Obviously, not all hosts are willing to use hierarchical HITs in all 256 scenarios for various reasons, such as privacy. Therefore, it is 257 useful that the hierarchical HIT architecture keep compatible with 258 the flat HIT architecture. 260 The flat HITs can be defined as a specific sub-set of the 261 hierarchical HITs architecture. With the same reserved Flat HIT Tag 262 (3 or 4 bits) at the beginning, for example, the left-most 3 bits is 263 000, the flat HITs can be used as defined in [RFC4423]. 265 | 128 bits | 266 +-----------------------------------------------------------------+ 267 |FHIT Tag| Flat host identity tag | 268 +-----------------------------------------------------------------+ 270 3.2. HITs on nodes 272 HIP-enabled nodes may have considerable or little knowledge of the 273 internal structure of hierarchical HITs, depending on the role the 274 node plays (for instance, host versus mapping server). At a 275 minimum, a node may consider pre-generated HITs have no internal 276 structure: 278 | 128 bits | 279 +-----------------------------------------------------------------+ 280 | host identity tag | 281 +-----------------------------------------------------------------+ 283 Only sophisticated hosts may additionally be aware of the type of 284 their HITS and use the hierarchical structure of HITs to simplify the 285 resolution procedure. 287 4. Generating a hierarchical HIT 289 The process of generating a new hierarchical HIT takes three input 290 values: an n-bit HIP AD ID, a 2-bit collusion count, (an example, it 291 is a subject to be changed in the future.) the host identity (the 292 public key of an asymmetric key pair). A hierarchical HIT should be 293 generated as follows: 295 1. Set the 2-bit collision count to zero. 297 2. Concatenate from left to right the HIP AD ID, the collusion 298 count, and the host identity. Execute the SHA-1 algorithm on 299 the concatenation. Take the (128-2-n) leftmost bits of the 300 SHA-1 hash value. 302 3. Concatenate from left to right the n-bit HIP AD ID, the 2-bit 303 collusion count and (128-2-n)-bit hash output to form a 128- 304 bit HIT. 306 4. Perform duplicate detection within the HIP administrative 307 domain scope. If a HIT collision is detected, increment the 308 collision count by one and go back to step 2. However, after 309 four collisions, stop and report the error. (Note: the 310 duplicate detection mechanism is not discussed in this 311 document. It may be broadcast or central registration.) 313 The design that includes the HIP AD ID in the hash input is mainly 314 against the re-computation attack: create a database of HITs and 315 matching public keys. With the design, an attacker must create a 316 separate database for each HIP administrative domain. 318 The design reduces the number of bit of hash output 2 bits lower. It 319 does reduce the safety. However, O(2^(128-2-n)) iterations is large 320 enough to prevent brute-force attacks. 322 For security reason, the abovementioned SHA-1 hash algorithm may be 323 replaced by any safer algorithm. 325 5. Requirements for modification on HIP 327 The usage of hierarchical HITs requires either a new version of HIP 328 protocol or a new critical flag in the header of HIP control 329 packets. The latter is considered easier and more fulfill. 331 6. Security Considerations 333 The most important security property of HIT is that it is self- 334 certifying (i.e., given a HIT, it is computationally hard to find a 335 Host Identity key that matches the HIT). Although this document 336 limits the hash output to be (128-2-n)-bit long, it does not affect 337 the self certifying security property. 339 7. IANA Considerations 341 This document defines a new namespace: HIP AD ID. It is an n-bit long 342 value, which represents a globally unique HIP administrative domain. 343 IANA may found an authority institute to manage the global assignment 344 of HIP AD ID. 346 8. Acknowledgements 348 Useful comments were made by Miika Komu from HIIT, and other members 349 of the IRTF HIPRG research group. 351 9. References 353 9.1. Normative References 355 [RFC2050] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg and J. 356 Postel "Internet Registry IP Allocation Guidelines", RFC 357 2050, November 1996 359 [RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol (HIP) 360 Architecture", RFC 4423, May 2006. 362 [RFC5201] R. Moskowitz, et al., "Host Identity Protocol", RFC 5201, 363 Oct 2007. 365 9.2. Informative References 367 [RFC4632] V. Fuller, T. Li, "Classless Inter-Domain Routing (CIDR): 368 The Internet Address Assignment and Aggregation Plan", 369 RFC4632, August 2006. 371 [RFC4843] P. Nikander, et al., "An IPv6 Prefix for Overlay Routable 372 Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 373 2007. 375 Author's Addresses 377 Sheng Jiang 378 Huawei Technologies Co., Ltd 379 KuiKe Building, No.9 Xinxi Rd., 380 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 381 P.R. China 382 Email: shengjiang@huawei.com 384 Xiaohu Xu 385 Huawei Technologies Co., Ltd 386 KuiKe Building, No.9 Xinxi Rd., 387 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 388 P.R. China 389 Email: xuxiaohu@huawei.com 391 Dacheng Zhang 392 Huawei Technologies Co., Ltd 393 KuiKe Building, No.9 Xinxi Rd., 394 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 395 P.R. China 396 Email: zhangdacheng@huawei.com 398 Tao Chen 399 CNNIC 400 No. 4, South 4th Street, Zhongguancun 401 Beijing 100190 402 P.R. China 403 Email: chentao@cnnic.cn