idnits 2.17.1 draft-moskowitz-hierarchical-hip-01.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 345 has weird spacing: '...rmation req...' -- The document date (September 26, 2016) is 2762 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 413, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-03 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: March 30, 2017 Huawei 6 September 26, 2016 8 Hierarchical HITs for HIPv2 9 draft-moskowitz-hierarchical-hip-01.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 March 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 . . . . . . . . . . . . . . . . . . . . . . . 14 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 157 [I-D.ietf-hip-rfc5204-bis] works with such a large population. There 158 is also the challenge of how to turn this into a viable business for 159 the Mobile Network Providers. 161 Even though the probability of collisions with 7B HITs in a 96 bit 162 flat address space is 3.9E-10, it is still real. How are collisions 163 managed? It is also possible that weak key uniqueness, as has been 164 shown in deployed TLS certificates, results in a much greater 165 probability of collisions. Thus resolution of collisions needs to be 166 a feature in a globally mobile network. 168 3.4. Defense against fraudulent HITs 170 How can a host protect against a fraudulent HIT? That is a second 171 pre-image attack on the HI hash that produces the HIT. A strong 172 defense would require every HIT/HI registered and openly verifiable. 173 This would best be done as part of the R1 and I2 validation. 175 3.5. Desire for administrative control by RVS providers 177 An RVS provider may only be willing to provide discovery (RVS) 178 services to HIP devices it knows and trusts. A flat HIT space does 179 not provide any intrinsic functionality to support this. A 180 hierarchical HIT space can be mapped to the RVS provider. DNS can 181 effectively be used to provide the HIT to IP mapping without DHT. 183 A hierarchical HIT space also creates a type of a business labeling 184 for the RVS provider. "These are my customers." 186 4. The Hierarchical Host Identity Tag (HIT) 188 The Hierarchical HIT is a small but important enhancement over the 189 flat HIT space. It represents the HI in only a 64 bit hash and uses 190 the other 32 bits to create a hierarchical administration 191 organization for HIT domains. Hierarchical HITs are ORCHIDs 192 [RFC7343]. The change in construction rules are in Section 4.1.4. 194 A Hierarchical HIT is built from the following fields: 196 o 28 bit IANA prefix 198 o 4 bit HIT Suite ID 200 o 32 bit Hierarchy ID (HID) 202 o 64 bit ORCHID hash 204 4.1. The Hierarchy ID (HID) 206 The Hierarchy ID (HID) provides the structure to organize HITs into 207 administrative domains. HIDs are further divided into 2 fields: 209 o 14 bit Registered Assigning Authority (RAA) 211 o 18 bit Hierarchical HIT Domain Authority (HDA) 213 4.1.1. The Registered Assigning Authority (RAA) 215 An RAA is a business that manages a registry of HDAs. 217 The RAA is a 14 bit field (16,384 RAAs) assigned sequentially by a 218 numbers management organization, perhaps ICANN's IANA service. An 219 RAA must provide a set of services to allocate HDAs to organizations. 220 It must have a public policy on what is necessary to obtain an HDA. 221 The RAA need not maintain any HIP related services. It must maintain 222 a DNS zone for discovering HID RVS servers. 224 This DNS zone may be a reverse PTR for its RAA. Assume that the RAA 225 is 100. The PTR record is constructed at a 2 bit grouping: 227 1.3.1.0.0.0.0.arpa IN PTR raa.bar.com. 229 4.1.2. The Hierarchical HIT Domain Authority (HDA) 231 An HDA may be an ISP or any third party that takes on the business to 232 provide RVS and other needed services for HIP enabled devices. 234 The HDA is an 18 bit field (262,144 HDAs per RAA) assigned 235 sequentially by an RAA. An HDA should maintain a set of RVS servers 236 that its client HIP-enabled customers use. How this is done and 237 scales to the potentially millions of customers is outside the scope 238 of this document. This service should be discoverable through the 239 DNS zone maintained by the HDA's RAA. 241 An RAA may assign a block of values to an individual organization. 242 This is completely up to the individual RAA's published policy for 243 delegation. 245 4.1.3. Example of the HID DNS 247 HID related services should be discoverable via DNS. For example the 248 RVS for a HID could be found via the following. Assume that the RAA 249 is 100 and the HDA is 50. The PTR record is constructed at a 2 bit 250 grouping: 252 2.0.3.0.0.0.0.0.0.1.3.1.0.0.0.0.hhit.arpa IN PTR rvs.foo.com. 254 The RAA is running its zone, 1.3.1.0.0.0.0.hhit.arpa under the 255 hhit.arpa zone. 257 4.1.4. Changes to ORCHIDv2 to support Hierarchical HITs 259 ORCHIDv2 [RFC7343] has a number of inputs including a context, some 260 header bits, the hash algorithm, and the public key. The output is a 261 96 bit value. Hierarchical HIT makes the following changes. The HID 262 is added as part of the header bits and the output is a 64 bit value, 263 derived the same way as the 96 bit hash. 265 Input := HID | HOST_ID 266 OGA ID := 4-bit Orchid Generation Algorithm identifier 267 The HIT Suite ID = 0x40 268 Hash Input := Context ID | Input 269 Same Context ID as HIPv2 270 Prefix := HIPv2 Prefix 271 HID := Hierarchy ID 272 Hash := Hash_function( Hash Input ) 273 Encode_64 := Same as Encode_96, but only 64 bits 274 ORCHID := Prefix | OGA ID | HID | Encode_64( Hash ) 276 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 277 as they are clearly separated by the distinct HIT Suite ID. 279 4.1.5. Collision risks with Hierarchical HITs 281 The 64 bit hash size does have an increased risk of collisions over 282 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 283 probability of a collision in a population of 66 million. The 284 probability goes up to 1% for a population of 663 million. See 285 Appendix A for the collision probability formula. 287 However, this risk of collision is within a single HDA. Further, all 288 HDAs are expected to provide a registration process for reverse 289 lookup validation. This registration process would reject a 290 collision, forcing the client to generate a new HI and thus 291 hierarchical HIT and reapplying to the registration process. 293 5. HIP Parameters 295 The HIP parameters carry information that is necessary for 296 establishing and maintaining a HIP association. For example, the 297 device's public keys as well as the signaling for negotiating ciphers 298 and payload handling are encapsulated in HIP parameters. Additional 299 information, meaningful for end hosts or middleboxes, may also be 300 included in HIP parameters. The specification of the HIP parameters 301 and their mapping to HIP packets and packet types is flexible to 302 allow HIP extensions to define new parameters and new protocol 303 behavior. 305 5.1. HIT_SUITE_LIST 307 The HIT_SUITE_LIST parameter contains a list of the supported HIT 308 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 309 Initiator can determine which source HIT Suite IDs are supported by 310 the Responder. The HIT_SUITE_LIST parameter is defined in 311 Section 5.2.10 of [RFC7401]. 313 The following HIT Suite IDs are defined for Hierarchical HITs, and 314 the relationship between the four-bit ID value used in the OGA ID 315 field and the eight-bit encoding within the HIT_SUITE_LIST ID field 316 is clarified: 318 HIT Suite Four-bit ID Eight-bit encoding 320 ECDSA/hier/SHA-256 4 0x40 322 Note that the Hierarchical HIP HIT Suite ID allows the devices to use 323 the hierarchical RVS discovery and authentication services to 324 validate the peer and discover available services. The Responder 325 SHOULD respond with a HIP hierarchical HIT suite ID when the HIT of 326 the Initiator is a HIP hierarchical HIT. 328 5.2. CLIENT_INFO 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 / Client Information / 336 / / 337 / +-------------------------------+ 338 / | Padding | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Type [TBD-IANA] 342 Length length in octets, excluding Type, Length, and 343 Padding 344 Client The information required by the HDA in the format 345 Information required by the HDA. 347 This parameter contains client information to include in the HIT 348 registration. The specific content and format is set by the HDA. 350 6. HHIT Registry services to support hierarchical HITs 352 Hierarchical HIT registration SHOULD be performed using the HIP 353 Registration Extension [I-D.ietf-hip-rfc5203-bis]. The client either 354 uses an X.509 certificate [I-D.ietf-hip-rfc6253-bis], or use a PSK, 355 as defined in Appendix A of HIP-DEX [I-D.ietf-hip-dex], to validate 356 the registration. 358 The Registration should include additional client information. This 359 information may be contained within the X.509 certificate and/or is 360 carried in the CLIENT_INFO parameter, see Section 5.2. The Registrar 361 can include its requirements in the R1 packet, and the client provide 362 its information in the I2 packet. This parameter may be encrypted 363 within the ENCRYPTED parameter. If the CLIENT_INFO contains Personal 364 Identifying Information (PII), then it MUST be placed into the 365 ENCRYPTED parameter. 367 The content and internal format of the CLIENT_INFO parameter is set 368 by the HDA's policy and is outside the scope of this document. 369 Examples of client information can by phone number, IMEI, and ICCID. 371 6.1. Hierarchical HIT Registration using X.509 Certificates 373 This requires the HIP client to possess a client certificate trusted 374 by the HDA/Registrar. Registration will either succeed or fail. 376 6.2. Hierarchical HIT Registration using a PSK 378 This requires the HIP client and the HDA/Registrar to share a PSK. 379 The PSK may already exist prior to starting the registration and just 380 be used within the registration. A PSK out-of-band exchange may be 381 triggered by performing the registration without any authentication. 383 If no client authentication is included in the I2 packet, the 384 registration fails with "No Authentication provided". If the I2 385 packet included the proper HDA required client information, the HDA 386 can use it to set up a side channel for an out-of-band delivery of a 387 PSK. And example of this would be to send an SMS message with the 388 PSK. Once the client possesses the PSK, it can rerun the 389 registration at which point the HI and HIT duplicate checks are 390 performed. 392 6.3. Hierarchical HIT Registration Type 394 The Registration Type used in the REG_REQUEST is: 396 Number Registration Type 397 ------ ----------------- 398 2 HIT Registration 400 6.4. Hierarchical HIT Registration Failure Type 402 The Registration may fail. In fact, with PSK, this may be the 403 response to expect an SMS message with the PSK to use in a second 404 registration request. Failure Types used in the REG_FAIL are: 406 Failure Type Reason 407 ------------ ----------------------- 408 [TBD-IANA] Hierarchical HIT Already Registered 409 [TBD-IANA] HI Already Registered 410 [TBD-IANA] Previously Registered HI with different device information 411 [TBD-IANA] No Authentication provided 412 [TBD-IANA] Invalid Authentication 413 [TBD-IANA] Invalid Authentication, new PSK sent via SMS 415 6.5. Registration failure behavior 417 If the failure type is "Hierarchical HIT Already Registered", the 418 client's HI is hashing to an existing HIT and must generate a new HI 419 and hierarchical HIT and reregister. If the failure is "HI Already 420 Registered", the client should assume it is registered. If the 421 failure is "Previously Registered HI with different device 422 information", either the client managed to generate a duplicate HI, 423 probably indicating a weak key generation algorithm, or the client 424 was previously registered on a different device. Resolving this 425 conflict will be left to the HDA's policy. 427 6.5.1. Example of a simple HDA policy 429 A simple HDA policy would be to require the device to generate a new 430 HI and thus HHIT and try registration again. The HDA policy may also 431 provide a URL for "Previous Registration Resolution". This contact 432 is primarily to assist a device that was registered, but had some 433 local failure resulting in a new registration attempt. 435 7. Using hierarchical HITs 437 All HIP clients with hierarchical HITs maintain an RVS connection 438 with their HDA's RVS server(s). How the HDA scales this service up 439 to a potential population in the millions is out of scope of this 440 document. Lifetime management of these connections is also out of 441 scope. 443 One approach an HDA can use to address the scaling challenge is to 444 add an internal level of hierarchy to assign a set number of devices 445 per RVS server. 447 Peering agreements between HDAs would allow for geographically close 448 RVS to a device. This may reduce the latency for use of a device's 449 current RVS. This is a subject of another document. 451 7.1. Contacting a HIP client 453 A service Initiator uses some service to discover the HIT of the 454 service Responder. The Initiator uses the hierarchical information 455 in the HIT to find the Responder's RVS. A trusted RVS discover 456 method could use the DNS PTR to RVS as shown in Section 4.1.3. An I1 457 is sent to that RVS which forwards it to the Responder. 459 The potential Responder uses the HIT in the I1 to query the 460 Initiator's RVS about the Initiator. The nature of information, and 461 method of communication are determined by the Initiator's HDA and the 462 Responder's (and or HDA's) relationship with it. Based on the 463 Responder's local policy, this information will be used to determine 464 if the contact is to be accepted. If accepted, the Responder may 465 proceed sending an R1 to the Initiator. It may alternatively 466 initiate some non-HIP process. 468 It should be noted that this R1 may contain a REG_INFO list for the 469 Initiator to validate that the Responder does offer the desired 470 service. 472 7.2. Defense against fraudulent HITs 474 Both the Initiator and Responder MAY validate a peer host as a 475 defense against a second pre-image attack on the HHIT. This may 476 occur via a CERT [I-D.ietf-hip-rfc6253-bis] in R1 or I2. It may be 477 through a back end process associated with the R1 or I2 validation to 478 look up the HHIT and retrieve the registered HI. 480 8. IANA Considerations 482 IANA will need to make the following changes to the "Host Identity 483 Protocol (HIP) Parameters" registries: 485 HIT Suite ID: This document defines the new HIT Suite "Hierarchy 486 with ECDSA/SHA256" (see Section 5.1). 488 CLIENT_INFO: This document defines the new CLIENT_INFO parameter 489 (see Section 5.2). The parameter value will be assigned by IANA. 491 Reg Type: This document defines the new Registration Type for the 492 REG_REQUEST parameter "HIT Registration" (see Section 6.3). 494 Reg Fail: This document defines the new Failure Types for the 495 REG_FAIL parameter (see Section 6.4). 497 9. RAA Management Organization Considerations 499 Introducing the RAA management organization may be the largest hurdle 500 for hierarchical HITs. Thus it would be best if this were adopted by 501 an organization already in the business of allocating numbers within 502 either the Internet or the Mobile, cellular, infrastructure. 504 One consideration would be to reserve the first N RAA values to map 505 to the existing DNS TLDs. For example, these TLDs can be organized 506 in an ascending order and numbered accordingly. Thus the 2 character 507 TLDs will be a lower number than the 3 character TLDs. After that, 508 it could be a first come, first numbered assignment process. 510 10. Security Considerations 512 There are potential risks with the hierarchical HIT, the Registry 513 service, and the discovery of potential peer hosts using its 514 hierarchical HIT. 516 A 64 bit hash space presents a real risk of second pre-image attacks. 517 The HHIT Registry services effectively block attempts to "take over" 518 a HHIT. It does not stop a rogue attempting to impersonate a known 519 HHIT. This attack can be mitigated by the Responder using DNS to 520 find the HI for the HHIT or the RVS for the HHIT that then provides 521 the registered HI. 523 The two risks with hierarchical HITs are the use of an invalid HID 524 and forced HIT collisions. The use of the "hhit.arpa." DNS zone is 525 a strong protection against invalid HIDs. Querying an HDA's RVS for 526 a HIT under the HDA protects against talking to unregistered clients. 527 The Registry service has direct protection against forced or 528 accidental HIT hash collisions. 530 By using the HIP Registration Extension, the Registry service is 531 protected from direct attacks. This service does rely on either the 532 integrity of a PKI service or an out-of-band PSK delivery process. 533 Thus the risk to the Registry service is highly related to the trust 534 in these authentication setup services. Further, the duplicate HI 535 resolution process may require human interaction with related social 536 engineering risks. 538 Finally the peer host discovery process relies on trusting the 539 finding the proper HDA for the host and its forwarding the I1 to the 540 proper Responder. A rogue RVS, impersonating the RVS for the HIT, 541 could redirect the I1 to a client that has forced a collision with 542 the HIT and the Initiator would be none the wiser. The only defense 543 against this is if the Initiator has some other source for the 544 Responder HI and validate the HI in the R1. 546 11. Acknowledgments 548 Sue Hares of Huawei contributed to the clarity in this document. 550 12. References 552 12.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, 556 DOI 10.17487/RFC2119, March 1997, 557 . 559 12.2. Informative References 561 [I-D.ietf-hip-dex] 562 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 563 draft-ietf-hip-dex-03 (work in progress), June 2016. 565 [I-D.ietf-hip-rfc5203-bis] 566 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 567 Registration Extension", draft-ietf-hip-rfc5203-bis-11 568 (work in progress), August 2016. 570 [I-D.ietf-hip-rfc5204-bis] 571 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 572 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-08 (work 573 in progress), August 2016. 575 [I-D.ietf-hip-rfc6253-bis] 576 Heer, T. and S. Varjonen, "Host Identity Protocol 577 Certificates", draft-ietf-hip-rfc6253-bis-09 (work in 578 progress), July 2016. 580 [I-D.irtf-hiprg-dht] 581 Ahrenholz, J., "Host Identity Protocol Distributed Hash 582 Table Interface", draft-irtf-hiprg-dht-05 (work in 583 progress), December 2011. 585 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 586 Routable Cryptographic Hash Identifiers Version 2 587 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 588 2014, . 590 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 591 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 592 RFC 7401, DOI 10.17487/RFC7401, April 2015, 593 . 595 Appendix A. Calculating Collision Probabilities 597 The accepted formula for calculating the probability of a collision 598 is: 600 p = 1 - e^{-k^2/(2n)} 602 P Collision Probability 603 n Total possible population 604 k Actual population 606 Authors' Addresses 608 Robert Moskowitz 609 Huawei 610 Oak Park, MI 48237 611 USA 613 Email: rgm@htt-consult.com 615 Xiaohu Xu 616 Huawei 617 Huawei Bld, No.156 Beiqing Rd. 618 Beijing, Hai-Dian District 100095 619 China 621 Email: xuxiaohu@huawei.com 623 Bingyang Liu 624 Huawei 625 Huawei Bld, No.156 Beiqing Rd. 626 Beijing, Hai-Dian District 100095 627 China 629 Email: xuxiaohu@huawei.com