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