idnits 2.17.1 draft-xu-hip-hierarchical-03.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 374 has weird spacing: '...DI Type type...' == Line 376 has weird spacing: '... Length lengt...' == Line 377 has weird spacing: '... Length lengt...' == Line 382 has weird spacing: '...t After the e...' == Line 384 has weird spacing: '...SIG alg sig...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2012) is 4425 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5201' is defined on line 646, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) ** Obsolete normative reference: RFC 5205 (Obsoleted by RFC 8005) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft S. Jiang 4 Intended status: Informational D. Zhang 5 Expires: September 13, 2012 Huawei Technologies Co.,Ltd 6 D. Korzun 7 HIIT 8 Z. Cao 9 March 12, 2012 11 Extensions of Host Identity Protocol (HIP) with Hierarchical Information 12 draft-xu-hip-hierarchical-03 14 Abstract 16 This document explores the benefits brought by extending the Host 17 Identity Protocol (HIP) with hierarchical information. In addition, 18 three types of candidate solutions are introduced. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 13, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Benefits introduced by Hierarchical Information . . . . . . . 3 62 3. Candidate Solutions . . . . . . . . . . . . . . . . . . . . . 4 63 4. Integrating Hierarchical Information into 128 Bits HITs . . . 5 64 4.1. Compatible flat-structured HITs . . . . . . . . . . . . . 7 65 4.2. HITs on nodes . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. Generating a hierarchical HIT . . . . . . . . . . . . . . 7 67 5. Transporting Hierarchical information outside HITs . . . . . . 8 68 5.1. Hierarchical_HIT Parameter . . . . . . . . . . . . . . . . 9 69 5.2. Hierarchical Information Registration . . . . . . . . . . 10 70 5.3. Domain Name System (DNS) Extension . . . . . . . . . . . . 10 71 6. Extending the length of HITs . . . . . . . . . . . . . . . . . 11 72 7. Analysis of the Three Solutions . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 While having obtained a tremendous success, the current Internet 84 architecture shows its limits in many aspects. For example, the 85 current Internet cannot well support the incorporation of mobile and 86 multi-homed terminals, lacks essential security mechanisms, and 87 suffers from the issues caused by the explosively increased lengths 88 of routing tables. In order to address these challenges, a 89 comprehensive solution, the Host Identity Protocol (HIP), was 90 proposed. A simple principle behind HIP is to separate hosts' 91 identities from their topological locations in the Internet. 92 Currently, the basic architectures and protocols of HIP have been 93 developed, which are security-inherited and provides essential 94 supports for mobility and multi-homing features. 96 There is no hierarchcial information in the current HITs; hosts in 97 the current HIP architecture are organized as all "flat". This is 98 largely because a flat HIP namespace is simple and easy to implement. 99 This document first discusses the issues with the flat HIP 100 architecture and analyzes the benefits brought by integrating 101 hierarchical information with HIP in terms of security, management, 102 integration with hierarchical overlays and etc. Then, this document 103 introduces several potential solutions which can be used to 104 facilitate the integration of hierarchical information. 106 2. Benefits introduced by Hierarchical Information 108 Hierarchy is a practical methodology in the design and organization 109 of non-trivial distributed systems, and has been adopted in many 110 large-scale networks and distributed systems (e.g., Internet). It 111 brought benefits in terms of simplifying system architectures, 112 improving the capability of system management, facilitating audit and 113 security, and etc. To be consistent with the hierarchical features 114 of the Internet, two critical namespaces of the Internet, IP and 115 FQDN, are designed in hierarchical ways. However, based on certain 116 concerns (e.g., easy implementation), the current HIT namespace is 117 flat; HIP itself does not provide any support for hierarchy either. 119 This section attempts to demonstrate that current HIP, by using 120 hierarchical information, can be more efficient and flexible in many 121 typical scenarios. 123 Firstly, hierarchical information is essential for the combination of 124 HIP with hierarchical overlays (e.g., hierarchical resolution 125 mechanisms). Compared with flat overlays where resources are 126 maintained at essentially random nodes, hierarchical overlays are 127 able to support reasonable business and trust models where resources 128 are managed by Administrative Domains (ADs) with distinct boundaries. 129 For example, it is normally not desired for a country to have its 130 resolution infrastructure and the related data resources managed by 131 other countries. In order to correctly route across hierarchical 132 overlays, hierarchical information (e.g., AD identifiers) is required 133 to identify the destination AD where the desired resources are 134 maintained, while the resource identifiers are used to locate the 135 resources. 137 Secondly, the hierarchical information can be used to address the 138 uniqueness verification issues with HITs in current HIP solutions. 139 In current HIP solutions, the HIT of each host is required to be 140 unique all over the world, which is very difficult to guarantee. 141 However, if the Internet is divided into multiple administration 142 domains, this problem is relatively easier to address. As 143 hierarchical information (i.e., AD identifier) can be used to 144 identify the AD of a HIT, it only needs to be guaranteed that the HIT 145 is unique within the AD. The process of verifying the uniqueness of 146 HITs can be performed when the host registers its HIT with the AD. 148 Moreover, hierarchical information has been widely employed in 149 advanced authorization systems (e.g., attributes based or role-based 150 authorization systems) to make the access control aggregates. By 151 using AD identifiers, it is possible for security managers to design 152 the access control policies based on the AD of hosts so as to reduce 153 the length of access control lists. In contrast, there is nothing 154 common between flat HITs that were assigned by the same authority or 155 that their represented hosts have the same properties, and thus they 156 are difficult to be categorized. 158 Apart from the advantages mentioned above, hierarchical information 159 may associate HIP with better HIT administrating and auditing 160 capabilities. The hierarchical information makes HITs more 161 aggregative; they can be grouped according to its belonging authority 162 or domain. Each network operator just needs to manage and maintain 163 HITs and their mapping information in a relatively small range. Such 164 advantages can make HIP easier to be accepted by the countries or 165 organizations which have relatively strict management policies on 166 their networks. 168 3. Candidate Solutions 170 There are various ways to integrate hierarchical information into the 171 HIP architecture. In the current version of document, we select 172 three representative candidates, and more solution may be introduced 173 in future versions. 175 The first type of solution is to embed hierarchical information into 176 HITs directly. For instance, divide a HIT into two parts; the first 177 part indicates the hierarchical information of the host, and the 178 second pare is the identifier of the host. The principle behind this 179 type of solution is similar with IP addresses. 181 The second type of solution is to transport hierarchical information 182 somewhere outside HITs, e.g., in a certificate or in a parameter. In 183 the preceding case, the certificate can be transported within the 184 CERT parameter of the HIT header. 186 The third type of solution is a hybrid of the above two types of 187 solutions. This type of solution extends the length of the 128 bits 188 HITs. The extended place is used to contain hierarchical 189 information. 191 4. Integrating Hierarchical Information into 128 Bits HITs 193 In this section, we introduce an example hierarchically structured 194 HIT namespace. In this hierarchical HIT namespace, a 128-bit HIT 195 consists of two parts: an n-bit HIP AD ID and a (128-n)-bit local 196 host ID. (n is a subject to be decided in the future.) It can 197 represent maximum 2^n administrative domains and 2^(128-n) hosts 198 within each administrative domain. The Administrative Domain ID has 199 embedded organizational affiliation and global uniqueness. The local 200 host ID is a hash over the AD ID and the public key of the ID owner. 201 | n bits | 128-n bits | 202 +-------------------------------+---------------------------------+ 203 | HIP Administrative Domain ID | local host ID | 204 +-------------------------------+---------------------------------+ 206 HIT with Hierarchical Information 208 Since the local host ID is a hash result, the strength of the local 209 host ID in tolerating brute-force attacks is affected by its length. 210 If the hash algorithm cannot be inverted, the expected number of 211 iterations required for a brute force attack is O(2^(128-n)) in order 212 to find a local host ID that matches with a given local host ID. 213 Therefore, for the secure consideration, we recommend to only assign 214 necessary bits for HIP administrative domain ID and leave space for 215 the local host ID as much as possible. It should be noted that this 216 draft does not take into account the ORCHID prefix defined in 217 [RFC4843] for two reasons: firstly, ORCHID is only temporary assigned 218 for experimental usage till 2014 only. The proposal design in the 219 document is targeting to be used continuously after 2014. Secondly, 220 the fixed 28-bit orchid prefix reduces the security properties 221 massively and increase collusion possibility highly. 223 The HIP administrative domain, as its literal, is a logic region in 224 which the HIs of all nodes are assigned by the same authority. 225 Within a same HIP administrative domain, all the nodes should have 226 the same HIP AD ID or the same leftmost certain bits. Furthermore, 227 the authority may be organized internally hierarchically. 229 The HIP AD ID should be assigned by a global administrative 230 organization with the principle that every HIP AD ID must be globally 231 unique. 233 Consequentially, the HIP AD IDs may be organized hierarchically. For 234 example, a big organization may obtain a block of HIP AD IDs with an 235 assigned 16-bit prefix. It then can assign 24-bit HIP AD IDs to its 236 sub-organizations. All these sub-organizations have the same 237 leftmost 16-bit. 239 One promising allocation solution of HIP AD ID is following current 240 routable IP address allocation system [RFC2050]. At first IANA 241 allocates some HIP AD ID prefixes to RIR (Region Internet Registry) 242 or NIR (National Internet Registry),then RIR or NIR sub-allocates the 243 HIP AD ID prefix to LIR or backbone ISP that subdivides the tag 244 prefix to middle or small ISP. Historical experience of routable IP 245 address allocation indicates that the allocation system can ensure 246 global uniqueness of HIP AD IDs. 248 An advantage of this solution is that the HHIT architecture can build 249 a distributed catalogue based on current IP address Internet 250 Registry. Each level Internet Registry only needs to maintain its 251 HHIT information. This catalogue is like current IP Whois Server 252 operated by each IP address Internet Registry. But it should include 253 many more attributes about a HHIT, such as organizational 254 affiliation, geographical information, privacy protection rule etc. 255 The catalogue should be independent of current IP Whois system and IP 256 address Internet Registry should provide some mechanism to translate 257 HHIT to its useful attributes on demand of various applications. 259 The local host IDs remains the original meaning of HIT - "a hashed 260 encoding of the Host Identity". For each HIP administrative domain, 261 it is mandatory to maintain the uniqueness of all local host IDs. It 262 is guaranteed by the process of generating a HIT, see Section 5. 264 For resolution purposes, HITs are aggregatable with AD IDs of 265 arbitrary bit-length, similar to IPv4 addresses under Classless 266 Inter-Domain Routing [RFC4632]. 268 4.1. Compatible flat-structured HITs 270 Obviously, not all hosts are willing to use hierarchical HITs in all 271 scenarios for various reasons, such as privacy. Therefore, it is 272 useful that the hierarchical HIT architecture keep compatible with 273 the flat HIT architecture. 275 The flat HITs can be defined as a specific sub-set of the 276 hierarchical HITs architecture. With the same reserved Flat HIT Tag 277 (3 or 4 bits) at the beginning, for example, the left-most 3 bits is 278 000, the flat HITs can be used as defined in [RFC4423]. 279 | 128 bits | 280 +-----------------------------------------------------------------+ 281 |FHIT Tag| Flat host identity tag | 282 +-----------------------------------------------------------------+ 284 4.2. HITs on nodes 286 HIP-enabled nodes may have considerable or little knowledge of the 287 internal structure of hierarchical HITs, depending on the role the 288 node plays (for instance, host versus mapping server). At a minimum, 289 a node may consider pre-generated HITs have no internal structure: 290 | 128 bits | 291 +-----------------------------------------------------------------+ 292 | host identity tag | 293 +-----------------------------------------------------------------+ 295 Only sophisticated hosts may additionally be aware of the type of 296 their HITS and use the hierarchical structure of HITs to simplify the 297 resolution procedure. 299 4.3. Generating a hierarchical HIT 301 The process of generating a new hierarchical HIT takes three input 302 values: an n-bit HIP AD ID, a 2-bit collusion count, (an example, it 303 is a subject to be changed in the future.) the host identity (the 304 public key of an asymmetric key pair). A hierarchical HIT should be 305 generated as follows: 307 1. Set the 2-bit collision count to zero. 309 2. Concatenate from left to right the HIP AD ID, the collusion 310 count, and the host identity. Execute the SHA-1 algorithm on the 311 concatenation. Take the (128-2-n) leftmost bits of the SHA-1 312 hash value. 314 3. Concatenate from left to right the n-bit HIP AD ID, the 2-bit 315 collusion count and (128-2-n)-bit hash output to form a 128-bit 316 HIT. 318 4. Perform duplicate detection within the HIP administrative domain 319 scope. If a HIT collision is detected, increment the collision 320 count by one and go back to step 2. However, after four 321 collisions, stop and report the error. (Note: the duplicate 322 detection mechanism is not discussed in this document. It may be 323 broadcast or central registration.) 325 The design that includes the HIP AD ID in the hash input is mainly 326 against the re-computation attack: create a database of HITs and 327 matching public keys. With the design, an attacker must create a 328 separate database for each HIP administrative domain. 330 The design reduces the number of bit of hash output 2 bits lower. It 331 does reduce the safety. However, O(2^(128-2-n)) iterations is large 332 enough to prevent brute-force attacks. 334 For security reason, the abovementioned SHA-1 hash algorithm may be 335 replaced by any safer algorithm. 337 5. Transporting Hierarchical information outside HITs 339 As mentioned previously, there are at least two methods of 340 transporting hierarchical information in HIP headers, i.e., using 341 certificates and using parameters. Compared with the certificate 342 oriented method, it is relatively more efficient to use parameters to 343 transport hierarchical information. For instance, some parameters of 344 a certificate (e.g., the name and the public key of the subject) are 345 already contained in HIT headers. When using a certificate to 346 transport hierarchical information, these parameters may have to be 347 transported again, causing redundancy. In addition, certificates 348 have to be signed by issuers. The signature of a certificate can be 349 used to verify the authenticity of the transported hierarchical 350 information, which is very useful when the certificate is used to 351 transport hierarchical information for the source HIT of a HIP 352 packet. However, when the certificate is used to transport 353 hierarchical information for the destination HIT of a HIP packet, the 354 signature is redundant because the receiver of the packet needs not 355 to verify the authenticity of its hierarchical information. Another 356 concern is performance. A HIT can be attached with multiple 357 certificates which are issued by diverse third parties for the 358 various purposes. The system thus may have to go through all the 359 certificates in order to find the proper certificate issued by the AD 360 and use it to assess the validity of the HIT. 362 In the remainder of this section, we mainly introduce an example 363 Hierarchical_HIT Parameter which is used to transport hierarchical 364 information. In addition, several associated extensions are 365 proposed. 367 5.1. Hierarchical_HIT Parameter 369 This parameter contains the information about the AD and should be 370 transported in R1 and I2 packets of basic. 372 Type 61698 373 Length length in octets, excluding Type, Length, and Padding 374 ADI Type type of the Administration Domain Identifier field 375 ADI Length length of the FQDN or NAI in octets 376 NB Length length of the Not Before Time field in octets 377 NA Length length of the Not After Time field in octets 378 AD the identifier of the AD of the sender 379 Identifier 380 Not Before the beginning of the valid period of the HIT of the sender 381 Time 382 Not After the end of the valid period of the HIT of the sender 383 Time 384 SIG alg signature algorithm 385 Signature the signature is generated by the AD previously, 386 calculated over the concatenation of Host Identity field 387 of HOST_ID, and AD Identifier, Not Before Time, Not After 388 Time fields of the Hierarchical_HIT parameter. 390 0 1 2 3 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |ADIType| ADI Length | NB Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | NA Length | Sig Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | SIG alg | AD Identifier / 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 / | Not Before Time / 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 / | Not After Time / 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 / | Signature / 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 / | Padding | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 The following ADI Types have been defined: 412 +------------------------------------------------------+-------+ 413 | Type | Value | 414 +------------------------------------------------------+-------+ 415 | none included | 0 | 416 | FQDN (Fully Qualified Domain Name, in binary format) | 1 | 417 | NAI (Network Access Identifier) | 2 | 418 +------------------------------------------------------+-------+ 420 The format for the FQDN is defined in[RFC1035] Section 3.1. The 421 format for NAI is defined in [RFC4282]. Not Before Time and Not 422 After Time fields can either UTCTime or GeneralizedTime defined in 423 [RFC2459]. SIG alg is set to 0 when there is no signature included. 424 In this case, Sig Length is set 0 as well. 426 Note that the parameter introduced in this section only consists of 427 very essential information. The parameter may need to be extended or 428 modified before being applied in future. 430 5.2. Hierarchical Information Registration 432 If the authenticity of the hierarchical information of a HIT needs to 433 be proved in practice, the HIT need to register with an AD and obtain 434 the signature. The registration process can be whether in-band or 435 out-of-band. In the following diagram, a protocol for hierarchical 436 information registration is illustrated. 437 +-----+ +------+ 438 | | I1 | | 439 | |--------------------------->| | 440 | |<---------------------------| | 441 | I | R1(REG_INFO) | AD | 442 | | I2(REG_REQ) |Server| 443 | |--------------------------->| | 444 | |<---------------------------| | 445 | | R2(REG_RES) | | 446 +-----+ +------+ 448 This protocol is an extension of basic by using the HIP Registration 449 Extension [RFC5203]. In R1, AD Server sends the service it provides 450 to Initiator in the REG_INFO element. Initiator then attaches the 451 REG-REQ element and the HHIT parameter with the I2 message. The 452 Signature field in the parameter is left unfilled. The AD server 453 signs the HHIT and its parameters, and sends the signature back in 454 R2. 456 5.3. Domain Name System (DNS) Extension 458 This section introduces a DNS extension which further extends the HIP 459 RR Storage Format proposed in [RFC5205]. 461 0 1 2 3 462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | HIT Length | PK algorithm | PK Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 |ADIType| ADI Length | NB Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | NA Length | HIT / 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 / | Public Key / 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 / | Rendezvous Server / 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 / | AD Identifier / 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 / | Not Before Time / 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 / | Not After Time / 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 / | 481 +-+-+-+-+ 483 Apart from the fields illustrated in [RFC5205], the extension 484 includes following fields: ADI type, ADI Length, NB Length, NA 485 Length, AD Identifier, Not Before Time, Not After Time. Because the 486 meanings of these fields is identical to their counterparts in the 487 Hierarchical_HIT Parameter, they are not introduced here in detail. 489 6. Extending the length of HITs 491 In this section, we introduce a hybrid of the above two types of 492 solutions. In this solution, hierarchical information is integrated 493 within HITs. Unlike the solution proposed in section 3, the space of 494 the flat hash part of a HIT does not have to be occupied. Instead, 495 the whole length of the HIT is extended, and the extended space is 496 used to contain the hierarchical information. An example of such 497 hierarchical HITs is presented in the following figure. 498 | 128 bits | 499 +-----------------------------------------------------------------+ 500 | hierarchical information part | 501 +-----------------------------------------------------------------+ 502 | flat hash part | 503 +-----------------------------------------------------------------+ 505 The enlarged HIT presented in the figure can be broken into two 506 parts: the hierarchical information part and the flat hash part. In 507 this example, the flat hash part is generated by hashing the 508 concatenation of hierarchical information part and the associated 509 public key. In order to keep enough capability in tolerating brute 510 force attacks and be compatible with TCP, it is recommended the flat 511 hash part is set 128 bits long. When receiving such a HIT, a user 512 only transfers the flat hash part to the TCP layer, and thus TCP will 513 treat it as an ordinary IPv6 address. 515 7. Analysis of the Three Solutions 517 A criticism on the first type of solution is that the capability of 518 an identifier in tolerating brute-force attacks is affected as a part 519 of the space of the identifier that is occupied by the topological 520 information. This issue can be largely addressed by puzzles which 521 have been employed in Cryptographically Generated Addresses (CGA) 522 [RFC3972]. Also, it is possible to extend the length of HITs to 523 enhance their tolerant capability on brute force attacks. 525 Another concern with hierarchical HITs is that they are not suitable 526 for the scenario where hosts do not intend to disclose their 527 hierarchical information. In section 4, these problems and 528 associated solutions are introduced. 530 The second type of solution allows a user to flexibly present or hide 531 the hierarchical information in various circumstances. A 532 disadvantage imposed by this type of solution is that more traffic 533 needs to be transported as both certificates and parameters may 534 contain redundant information. 536 Compared with the first type of solution, the capability of the third 537 type of solution in tolerating brute force attacks is not influenced. 538 Additionally, compared with the second type of solution, the third 539 type of solution avoids transporting the redundant information. 540 However, a disadvantage of the third type of solution is that it 541 modifies the architecture of HIP headers. 543 8. IANA Considerations 545 The namespace, HIP AD ID, defined in section 4 is an n-bit long 546 value, which represents a globally unique HIP administrative domain. 547 IANA may found an authority institute to manage the global assignment 548 of HIP AD ID. 550 Additionally, IANA is expected to allocate a type code for the 551 Hierarchical_HIT Parameter illustrated in section 5. 553 Note to RFC Editor: this section may be removed on publication as an 554 RFC. 556 9. Security Considerations 558 The hierarchical HIT routing infrastructure provides some mechanisms 559 for defending attacks (e.g., proving HIT ownership, certificate 560 binding hierarchical HITs to a trusted third party, or random AD 561 IDs). Below we list some possible attacks on hierarchical HITs. 563 Forging hierarchical HITs. An attacker generates a HIT with certain 564 attack-suitable properties for using it for further attacks. 565 Classes of such properties are listed below. For checking the 566 existence of a HIT, the name resolution system (DNS/DHT) can be 567 used. 569 Intrusion. Generation of HITs belonging to some organization. As 570 a result the attacker can participate in communications between 571 organization's hosts. Organization's AD ID is known to the 572 attacker, and 64-bit hash value is generated. The attacker has 573 to prove the ownership of that HIT since it does not have the 574 private key. 576 Substitution. An attacker tries to use the HIT already existed in 577 the organization. As a result, the attacker substitutes good 578 host. Generation of HITs (64 bits of hash value) randomly or 579 by enumeration. For every HIT the attacker tries to join the 580 system. 582 Cutting. AD ID can code a hierarchy with in a large organization. 583 The hierarchy of AD ID is based on prefixes. As a result, an 584 attacker can generate a HIT that shares a prefix with the AD ID 585 of the organization. Hence the attacker cuts a part of HIT 586 space. Similarly to intrusion and substitution except that the 587 generated HITs share some prefix with the given AD ID. 589 Accumulation. Valid HITs can be prepared in advance, i.e., 590 collected in a database. Similarly to substitution attack, the 591 attacker generates HITs and tries to join. Is it possible to 592 identify that the HIT is in use and what is the ratio of 593 successful identifications (does HIT exist or not) . 595 Sybils. Introduction of many forged HITs. They incrementally 596 appear in the system. The attacker has a host with a valid HIT 597 joined to the system. Can this host introduce new participants 598 (with new HITs) easier than a newcomer without a protege. 600 Denial of Service. The hierarchical HIT infrastructure consists of 601 DNS and DHT servers. In addition, there can be third-party 602 servers, e.g., for license binding. All such servers are a target 603 to DoS attacks, including DDoS. 605 1. Generation of a high-rate request flow to a DNS server. 607 2. Generation of a high-rate request flow to a DHT server (or a 608 set of severs of a given organization). 610 3. Generation of a high-rate request flow to a third-party 611 server. It controls its service rate limiting incoming 612 requests. 614 Pollution. Similarly to DoS attacks, DNS and DHT servers are target 615 to incorrect data.1. The attacker tries to store bogus AAAA 616 records for hierarchical HIT in DNS. 2. Similarly to the 617 intrusion and substitution attacks, the attacker tries to insert 618 bogus HITs into DHT system of a given organization. 620 10. Acknowledgements 622 Thanks Thomas. R. Henderson for his kindly prove-reading and 623 precious comments. 625 11. References 627 11.1. Normative References 629 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 630 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 631 BCP 12, RFC 2050, November 1996. 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, March 1997. 636 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 637 X.509 Public Key Infrastructure Certificate and CRL 638 Profile", RFC 2459, January 1999. 640 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 641 Network Access Identifier", RFC 4282, December 2005. 643 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 644 (HIP) Architecture", RFC 4423, May 2006. 646 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 647 "Host Identity Protocol", RFC 5201, April 2008. 649 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 650 Protocol (HIP) Registration Extension", RFC 5203, 651 April 2008. 653 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 654 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 655 April 2008. 657 11.2. Informative References 659 [RFC1035] Mockapetris, P., "Domain names - implementation and 660 specification", STD 13, RFC 1035, November 1987. 662 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 663 RFC 3972, March 2005. 665 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 666 (CIDR): The Internet Address Assignment and Aggregation 667 Plan", BCP 122, RFC 4632, August 2006. 669 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 670 for Overlay Routable Cryptographic Hash Identifiers 671 (ORCHID)", RFC 4843, April 2007. 673 Authors' Addresses 675 Xiaohu Xu 676 Huawei Technologies Co.,Ltd 677 HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 678 Beijing, 100085 679 P. R. China 681 Phone: 682 Fax: 683 Email: xuxh@huawei.com 684 URI: 686 Sheng Jiang 687 Huawei Technologies Co.,Ltd 688 HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 689 Beijing, 100085 690 P. R. China 692 Phone: 693 Fax: 694 Email: shengjiang@huawei.com 695 URI: 697 Dacheng Zhang 698 Huawei Technologies Co.,Ltd 699 HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 700 Beijing, 100085 701 P. R. China 703 Phone: 704 Fax: 705 Email: zhangdacheng@huawei.com 706 URI: 708 Dmitry Korzun 709 HIIT 711 Phone: 712 Fax: 713 Email: Dmitry.Korzun@hiit.fi 714 URI: 716 Zhen Cao 717 Xuanwumenxi Ave. No.32 718 Beijing, 100053 719 China 721 Phone: 86-10-52686688 722 Fax: 723 Email: zehn.cao@gmail.com, caozhen@chinamobile.com 724 URI: