idnits 2.17.1 draft-moskowitz-hierarchical-hip-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 is 1 instance of too long lines in the document, the longest one being 4 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 344 has weird spacing: '...rmation req...' -- The document date (October 27, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD-IANA' is mentioned on line 411, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft X. Xu 4 Intended status: Standards Track B. Liu 5 Expires: April 30, 2017 Huawei 6 October 27, 2016 8 Hierarchical HITs for HIPv2 9 draft-moskowitz-hierarchical-hip-02.txt 11 Abstract 13 This document describes using a hierarchical HIT to facilitate large 14 deployments in mobile networks. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 30, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 53 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Meeting the future of Mobile Networking . . . . . . . . . 3 56 3.2. Semi-permanency of Identities . . . . . . . . . . . . . . 4 57 3.3. Managing a large flat address space . . . . . . . . . . . 4 58 3.4. Defense against fraudulent HITs . . . . . . . . . . . . . 4 59 3.5. Desire for administrative control by RVS providers . . . 4 60 4. The Hierarchical Host Identity Tag (HIT) . . . . . . . . . . 5 61 4.1. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 5 62 4.1.1. The Registered Assigning Authority (RAA) . . . . . . 5 63 4.1.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 5 64 4.1.3. Example of the HID DNS . . . . . . . . . . . . . . . 6 65 4.1.4. Changes to ORCHIDv2 to support Hierarchical HITs . . 6 66 4.1.5. Collision risks with Hierarchical HITs . . . . . . . 7 67 5. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . . 7 69 5.2. CLIENT_INFO . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. HHIT Registry services to support hierarchical HITs . . . . . 8 71 6.1. Hierarchical HIT Registration using X.509 Certificates . 8 72 6.2. Hierarchical HIT Registration using a PSK . . . . . . . . 9 73 6.3. Hierarchical HIT Registration Type . . . . . . . . . . . 9 74 6.4. Hierarchical HIT Registration Failure Type . . . . . . . 9 75 6.5. Registration failure behavior . . . . . . . . . . . . . . 9 76 6.5.1. Example of a simple HDA policy . . . . . . . . . . . 10 77 7. Using hierarchical HITs . . . . . . . . . . . . . . . . . . . 10 78 7.1. Contacting a HIP client . . . . . . . . . . . . . . . . . 10 79 7.2. Defense against fraudulent HITs . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 9. RAA Management Organization Considerations . . . . . . . . . 11 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 12.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Appendix A. Calculating Collision Probabilities . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 This document expands on HIPv2 [RFC7401] to describe the structure of 93 a hierarchical HIT, the Registry services to support this hierarchy, 94 and given a hierarchical HIT, how a device is found in the network. 96 A separate document will further expand on the registry service and 97 how a device can advertise its availability and services provided. 99 2. Terms and Definitions 101 2.1. Requirements Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2.2. Definitions 109 HDA (Hierarchical HIT Domain Authority): The 14 bit field 110 identifying the HIT Domain Authority under a RAA. 112 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 114 RAA (Registered Assigning Authority): The 18 bit field identifying 115 the Hierarchical HIT Assigning Authority. 117 3. Problem Space 119 3.1. Meeting the future of Mobile Networking 121 The evolution of mobile networking to greater bandwidth and faster 122 mobility will favor IP mobility technologies that optimize shortest 123 routing paths for both mobile-to-stationary and mobile-to-mobile 124 applications. For this, devices will need to use the IP address 125 which provide the shortest path for where they are physically in the 126 mobile network. The mobile device will need services that will 127 discover this IP addresses for their peer mobile devices and keep 128 them connected to those peers even when both devices move in the 129 network at the same time (the double-jump problem). In order to 130 support these services, there needs to be billable services to 131 support the infrastructure. In some area close tracking of mobile 132 devices will be mandatory. In other device obfuscation to protect 133 privacy and/or safety will be the only life-enabling approach. 135 These conflicting requirements can be met with the Host Identity 136 Protocol (HIP), provided its Rendezvous Server service is scaleable 137 and manageable. Providers of RVS will need both a viable and 138 scaleable business model. 140 3.2. Semi-permanency of Identities 142 A device Identity has some degree of permanency. A device creates 143 its identity and registers it some 3rd-party that will assert a level 144 of trust for that identity. A device may have multiple identities to 145 use in different contexts, and it may deprecate an identity for any 146 number of reasons. The asserting 3rd-party may withdraw its 147 assertion of an identity for any number of reasons. An identity 148 system needs to facilitate all of this. 150 3.3. Managing a large flat address space 152 For HIP to be successfully used in large mobile networks, it must 153 support an Identity per device, or at least 10 billion Identities. 154 Perhaps a Distributed Hash Table [I-D.irtf-hiprg-dht] can scale this 155 large. There is still the operational challenges in establishing 156 such a world-wide DHT implementation and how RVS [RFC8004] works with 157 such a large population. There is also the challenge of how to turn 158 this into a viable business for the Mobile Network Providers. 160 Even though the probability of collisions with 7B HITs in a 96 bit 161 flat address space is 3.9E-10, it is still real. How are collisions 162 managed? It is also possible that weak key uniqueness, as has been 163 shown in deployed TLS certificates, results in a much greater 164 probability of collisions. Thus resolution of collisions needs to be 165 a feature in a globally mobile network. 167 3.4. Defense against fraudulent HITs 169 How can a host protect against a fraudulent HIT? That is a second 170 pre-image attack on the HI hash that produces the HIT. A strong 171 defense would require every HIT/HI registered and openly verifiable. 172 This would best be done as part of the R1 and I2 validation. 174 3.5. Desire for administrative control by RVS providers 176 An RVS provider may only be willing to provide discovery (RVS) 177 services to HIP devices it knows and trusts. A flat HIT space does 178 not provide any intrinsic functionality to support this. A 179 hierarchical HIT space can be mapped to the RVS provider. DNS can 180 effectively be used to provide the HIT to IP mapping without DHT. 182 A hierarchical HIT space also creates a type of a business labeling 183 for the RVS provider. "These are my customers." 185 4. The Hierarchical Host Identity Tag (HIT) 187 The Hierarchical HIT is a small but important enhancement over the 188 flat HIT space. It represents the HI in only a 64 bit hash and uses 189 the other 32 bits to create a hierarchical administration 190 organization for HIT domains. Hierarchical HITs are ORCHIDs 191 [RFC7343]. The change in construction rules are in Section 4.1.4. 193 A Hierarchical HIT is built from the following fields: 195 o 28 bit IANA prefix 197 o 4 bit HIT Suite ID 199 o 32 bit Hierarchy ID (HID) 201 o 64 bit ORCHID hash 203 4.1. The Hierarchy ID (HID) 205 The Hierarchy ID (HID) provides the structure to organize HITs into 206 administrative domains. HIDs are further divided into 2 fields: 208 o 14 bit Registered Assigning Authority (RAA) 210 o 18 bit Hierarchical HIT Domain Authority (HDA) 212 4.1.1. The Registered Assigning Authority (RAA) 214 An RAA is a business that manages a registry of HDAs. 216 The RAA is a 14 bit field (16,384 RAAs) assigned sequentially by a 217 numbers management organization, perhaps ICANN's IANA service. An 218 RAA must provide a set of services to allocate HDAs to organizations. 219 It must have a public policy on what is necessary to obtain an HDA. 220 The RAA need not maintain any HIP related services. It must maintain 221 a DNS zone for discovering HID RVS servers. 223 This DNS zone may be a reverse PTR for its RAA. Assume that the RAA 224 is 100. The PTR record is constructed at a 2 bit grouping: 226 0.1.2.1.0.0.0.hhit.arpa IN PTR raa.bar.com. 228 4.1.2. The Hierarchical HIT Domain Authority (HDA) 230 An HDA may be an ISP or any third party that takes on the business to 231 provide RVS and other needed services for HIP enabled devices. 233 The HDA is an 18 bit field (262,144 HDAs per RAA) assigned 234 sequentially by an RAA. An HDA should maintain a set of RVS servers 235 that its client HIP-enabled customers use. How this is done and 236 scales to the potentially millions of customers is outside the scope 237 of this document. This service should be discoverable through the 238 DNS zone maintained by the HDA's RAA. 240 An RAA may assign a block of values to an individual organization. 241 This is completely up to the individual RAA's published policy for 242 delegation. 244 4.1.3. Example of the HID DNS 246 HID related services should be discoverable via DNS. For example the 247 RVS for a HID could be found via the following. Assume that the RAA 248 is 100 and the HDA is 50. The PTR record is constructed at a 2 bit 249 grouping: 251 2.0.3.0.0.0.0.0.0.1.3.1.0.0.0.0.hhit.arpa IN PTR rvs.foo.com. 253 The RAA is running its zone, 1.3.1.0.0.0.0.hhit.arpa under the 254 hhit.arpa zone. 256 4.1.4. Changes to ORCHIDv2 to support Hierarchical HITs 258 ORCHIDv2 [RFC7343] has a number of inputs including a context, some 259 header bits, the hash algorithm, and the public key. The output is a 260 96 bit value. Hierarchical HIT makes the following changes. The HID 261 is added as part of the header bits and the output is a 64 bit value, 262 derived the same way as the 96 bit hash. 264 Input := HID | HOST_ID 265 OGA ID := 4-bit Orchid Generation Algorithm identifier 266 The HIT Suite ID = 0x40 267 Hash Input := Context ID | Input 268 Same Context ID as HIPv2 269 Prefix := HIPv2 Prefix 270 HID := Hierarchy ID 271 Hash := Hash_function( Hash Input ) 272 Encode_64 := Same as Encode_96, but only 64 bits 273 ORCHID := Prefix | OGA ID | HID | Encode_64( Hash ) 275 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 276 as they are clearly separated by the distinct HIT Suite ID. 278 4.1.5. Collision risks with Hierarchical HITs 280 The 64 bit hash size does have an increased risk of collisions over 281 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 282 probability of a collision in a population of 66 million. The 283 probability goes up to 1% for a population of 663 million. See 284 Appendix A for the collision probability formula. 286 However, this risk of collision is within a single HDA. Further, all 287 HDAs are expected to provide a registration process for reverse 288 lookup validation. This registration process would reject a 289 collision, forcing the client to generate a new HI and thus 290 hierarchical HIT and reapplying to the registration process. 292 5. HIP Parameters 294 The HIP parameters carry information that is necessary for 295 establishing and maintaining a HIP association. For example, the 296 device's public keys as well as the signaling for negotiating ciphers 297 and payload handling are encapsulated in HIP parameters. Additional 298 information, meaningful for end hosts or middleboxes, may also be 299 included in HIP parameters. The specification of the HIP parameters 300 and their mapping to HIP packets and packet types is flexible to 301 allow HIP extensions to define new parameters and new protocol 302 behavior. 304 5.1. HIT_SUITE_LIST 306 The HIT_SUITE_LIST parameter contains a list of the supported HIT 307 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 308 Initiator can determine which source HIT Suite IDs are supported by 309 the Responder. The HIT_SUITE_LIST parameter is defined in 310 Section 5.2.10 of [RFC7401]. 312 The following HIT Suite IDs are defined for Hierarchical HITs, and 313 the relationship between the four-bit ID value used in the OGA ID 314 field and the eight-bit encoding within the HIT_SUITE_LIST ID field 315 is clarified: 317 HIT Suite Four-bit ID Eight-bit encoding 319 ECDSA/hier/SHA-256 4 0x40 321 Note that the Hierarchical HIP HIT Suite ID allows the devices to use 322 the hierarchical RVS discovery and authentication services to 323 validate the peer and discover available services. The Responder 324 SHOULD respond with a HIP hierarchical HIT suite ID when the HIT of 325 the Initiator is a HIP hierarchical HIT. 327 5.2. CLIENT_INFO 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 / Client Information / 335 / / 336 / +-------------------------------+ 337 / | Padding | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Type [TBD-IANA] 341 Length length in octets, excluding Type, Length, and 342 Padding 343 Client The information required by the HDA in the format 344 Information required by the HDA. 346 This parameter contains client information to include in the HIT 347 registration. The specific content and format is set by the HDA. 349 6. HHIT Registry services to support hierarchical HITs 351 Hierarchical HIT registration SHOULD be performed using the HIP 352 Registration Extension [RFC8003]. The client either uses an X.509 353 certificate [RFC8002], or use a PSK, as defined in Appendix A of HIP- 354 DEX [I-D.ietf-hip-dex], to validate the registration. 356 The Registration should include additional client information. This 357 information may be contained within the X.509 certificate and/or is 358 carried in the CLIENT_INFO parameter, see Section 5.2. The Registrar 359 can include its requirements in the R1 packet, and the client provide 360 its information in the I2 packet. This parameter may be encrypted 361 within the ENCRYPTED parameter. If the CLIENT_INFO contains Personal 362 Identifying Information (PII), then it MUST be placed into the 363 ENCRYPTED parameter. 365 The content and internal format of the CLIENT_INFO parameter is set 366 by the HDA's policy and is outside the scope of this document. 367 Examples of client information can by phone number, IMEI, and ICCID. 369 6.1. Hierarchical HIT Registration using X.509 Certificates 371 This requires the HIP client to possess a client certificate trusted 372 by the HDA/Registrar. Registration will either succeed or fail. 374 6.2. Hierarchical HIT Registration using a PSK 376 This requires the HIP client and the HDA/Registrar to share a PSK. 377 The PSK may already exist prior to starting the registration and just 378 be used within the registration. A PSK out-of-band exchange may be 379 triggered by performing the registration without any authentication. 381 If no client authentication is included in the I2 packet, the 382 registration fails with "No Authentication provided". If the I2 383 packet included the proper HDA required client information, the HDA 384 can use it to set up a side channel for an out-of-band delivery of a 385 PSK. And example of this would be to send an SMS message with the 386 PSK. Once the client possesses the PSK, it can rerun the 387 registration at which point the HI and HIT duplicate checks are 388 performed. 390 6.3. Hierarchical HIT Registration Type 392 The Registration Type used in the REG_REQUEST is: 394 Number Registration Type 395 ------ ----------------- 396 2 HIT Registration 398 6.4. Hierarchical HIT Registration Failure Type 400 The Registration may fail. In fact, with PSK, this may be the 401 response to expect an SMS message with the PSK to use in a second 402 registration request. Failure Types used in the REG_FAIL are: 404 Failure Type Reason 405 ------------ ----------------------- 406 [TBD-IANA] Hierarchical HIT Already Registered 407 [TBD-IANA] HI Already Registered 408 [TBD-IANA] Previously Registered HI with different device information 409 [TBD-IANA] No Authentication provided 410 [TBD-IANA] Invalid Authentication 411 [TBD-IANA] Invalid Authentication, new PSK sent via SMS 413 6.5. Registration failure behavior 415 If the failure type is "Hierarchical HIT Already Registered", the 416 client's HI is hashing to an existing HIT and must generate a new HI 417 and hierarchical HIT and reregister. If the failure is "HI Already 418 Registered", the client should assume it is registered. If the 419 failure is "Previously Registered HI with different device 420 information", either the client managed to generate a duplicate HI, 421 probably indicating a weak key generation algorithm, or the client 422 was previously registered on a different device. Resolving this 423 conflict will be left to the HDA's policy. 425 6.5.1. Example of a simple HDA policy 427 A simple HDA policy would be to require the device to generate a new 428 HI and thus HHIT and try registration again. The HDA policy may also 429 provide a URL for "Previous Registration Resolution". This contact 430 is primarily to assist a device that was registered, but had some 431 local failure resulting in a new registration attempt. 433 7. Using hierarchical HITs 435 All HIP clients with hierarchical HITs maintain an RVS connection 436 with their HDA's RVS server(s). How the HDA scales this service up 437 to a potential population in the millions is out of scope of this 438 document. Lifetime management of these connections is also out of 439 scope. 441 One approach an HDA can use to address the scaling challenge is to 442 add an internal level of hierarchy to assign a set number of devices 443 per RVS server. 445 Peering agreements between HDAs would allow for geographically close 446 RVS to a device. This may reduce the latency for use of a device's 447 current RVS. This is a subject of another document. 449 7.1. Contacting a HIP client 451 A service Initiator uses some service to discover the HIT of the 452 service Responder. The Initiator uses the hierarchical information 453 in the HIT to find the Responder's RVS. A trusted RVS discover 454 method could use the DNS PTR to RVS as shown in Section 4.1.3. An I1 455 is sent to that RVS which forwards it to the Responder. 457 The potential Responder uses the HIT in the I1 to query the 458 Initiator's RVS about the Initiator. The nature of information, and 459 method of communication are determined by the Initiator's HDA and the 460 Responder's (and or HDA's) relationship with it. Based on the 461 Responder's local policy, this information will be used to determine 462 if the contact is to be accepted. If accepted, the Responder may 463 proceed sending an R1 to the Initiator. It may alternatively 464 initiate some non-HIP process. 466 It should be noted that this R1 may contain a REG_INFO list for the 467 Initiator to validate that the Responder does offer the desired 468 service. 470 7.2. Defense against fraudulent HITs 472 Both the Initiator and Responder MAY validate a peer host as a 473 defense against a second pre-image attack on the HHIT. This may 474 occur via a CERT [RFC8002] in R1 or I2. It may be through a back end 475 process associated with the R1 or I2 validation to look up the HHIT 476 and retrieve the registered HI. 478 8. IANA Considerations 480 IANA will need to make the following changes to the "Host Identity 481 Protocol (HIP) Parameters" registries: 483 HIT Suite ID: This document defines the new HIT Suite "Hierarchy 484 with ECDSA/SHA256" (see Section 5.1). 486 CLIENT_INFO: This document defines the new CLIENT_INFO parameter 487 (see Section 5.2). The parameter value will be assigned by IANA. 489 Reg Type: This document defines the new Registration Type for the 490 REG_REQUEST parameter "HIT Registration" (see Section 6.3). 492 Reg Fail: This document defines the new Failure Types for the 493 REG_FAIL parameter (see Section 6.4). 495 9. RAA Management Organization Considerations 497 Introducing the RAA management organization may be the largest hurdle 498 for hierarchical HITs. Thus it would be best if this were adopted by 499 an organization already in the business of allocating numbers within 500 either the Internet or the Mobile, cellular, infrastructure. 502 One consideration would be to reserve the first N RAA values to map 503 to the existing DNS TLDs. For example, these TLDs can be organized 504 in an ascending order and numbered accordingly. Thus the 2 character 505 TLDs will be a lower number than the 3 character TLDs. After that, 506 it could be a first come, first numbered assignment process. 508 10. Security Considerations 510 There are potential risks with the hierarchical HIT, the Registry 511 service, and the discovery of potential peer hosts using its 512 hierarchical HIT. 514 A 64 bit hash space presents a real risk of second pre-image attacks. 515 The HHIT Registry services effectively block attempts to "take over" 516 a HHIT. It does not stop a rogue attempting to impersonate a known 517 HHIT. This attack can be mitigated by the Responder using DNS to 518 find the HI for the HHIT or the RVS for the HHIT that then provides 519 the registered HI. 521 The two risks with hierarchical HITs are the use of an invalid HID 522 and forced HIT collisions. The use of the "hhit.arpa." DNS zone is 523 a strong protection against invalid HIDs. Querying an HDA's RVS for 524 a HIT under the HDA protects against talking to unregistered clients. 525 The Registry service has direct protection against forced or 526 accidental HIT hash collisions. 528 By using the HIP Registration Extension, the Registry service is 529 protected from direct attacks. This service does rely on either the 530 integrity of a PKI service or an out-of-band PSK delivery process. 531 Thus the risk to the Registry service is highly related to the trust 532 in these authentication setup services. Further, the duplicate HI 533 resolution process may require human interaction with related social 534 engineering risks. 536 Finally the peer host discovery process relies on trusting the 537 finding the proper HDA for the host and its forwarding the I1 to the 538 proper Responder. A rogue RVS, impersonating the RVS for the HIT, 539 could redirect the I1 to a client that has forced a collision with 540 the HIT and the Initiator would be none the wiser. The only defense 541 against this is if the Initiator has some other source for the 542 Responder HI and validate the HI in the R1. 544 11. Acknowledgments 546 Sue Hares of Huawei contributed to the clarity in this document. 548 12. References 550 12.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 12.2. Informative References 559 [I-D.ietf-hip-dex] 560 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 561 draft-ietf-hip-dex-04 (work in progress), October 2016. 563 [I-D.irtf-hiprg-dht] 564 Ahrenholz, J., "Host Identity Protocol Distributed Hash 565 Table Interface", draft-irtf-hiprg-dht-05 (work in 566 progress), December 2011. 568 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 569 Routable Cryptographic Hash Identifiers Version 2 570 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 571 2014, . 573 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 574 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 575 RFC 7401, DOI 10.17487/RFC7401, April 2015, 576 . 578 [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol 579 Certificates", RFC 8002, DOI 10.17487/RFC8002, October 580 2016, . 582 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 583 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 584 October 2016, . 586 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 587 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 588 October 2016, . 590 Appendix A. Calculating Collision Probabilities 592 The accepted formula for calculating the probability of a collision 593 is: 595 p = 1 - e^{-k^2/(2n)} 597 P Collision Probability 598 n Total possible population 599 k Actual population 601 Authors' Addresses 602 Robert Moskowitz 603 Huawei 604 Oak Park, MI 48237 605 USA 607 Email: rgm@labs.htt-consult.com 609 Xiaohu Xu 610 Huawei 611 Huawei Bld, No.156 Beiqing Rd. 612 Beijing, Hai-Dian District 100095 613 China 615 Email: xuxiaohu@huawei.com 617 Bingyang Liu 618 Huawei 619 Huawei Bld, No.156 Beiqing Rd. 620 Beijing, Hai-Dian District 100095 621 China 623 Email: xuxiaohu@huawei.com