idnits 2.17.1 draft-moskowitz-hierarchical-hip-05.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 (December 21, 2017) is 2317 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 412, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-06 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: June 24, 2018 Huawei 6 December 21, 2017 8 Hierarchical HITs for HIPv2 9 draft-moskowitz-hierarchical-hip-05.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 June 24, 2018. 33 Copyright Notice 35 Copyright (c) 2017 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 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 12 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 12.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Appendix A. Calculating Collision Probabilities . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 This document expands on HIPv2 [RFC7401] to describe the structure of 94 a hierarchical HIT, the Registry services to support this hierarchy, 95 and given a hierarchical HIT, how a device is found in the network. 97 Separate documents will further expand on the registry service and 98 how a device can advertise its availability and services provided. 100 2. Terms and Definitions 102 2.1. Requirements Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2.2. Definitions 110 HDA (Hierarchical HIT Domain Authority): The 14 bit field 111 identifying the HIT Domain Authority under a RAA. 113 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 115 RAA (Registered Assigning Authority): The 18 bit field identifying 116 the Hierarchical HIT Assigning Authority. 118 3. Problem Space 120 3.1. Meeting the future of Mobile Networking 122 The evolution of mobile networking to greater bandwidth and faster 123 mobility will favor IP mobility technologies that optimize shortest 124 routing paths for both mobile-to-stationary and mobile-to-mobile 125 applications. For this, devices will need to use the IP address 126 which provide the shortest path for where they are physically in the 127 mobile network. The mobile device will need services that will 128 discover the IP addresses for their peer mobile devices and keep them 129 connected to those peers even when both devices move in the network 130 at the same time (the double-jump problem). In order to support 131 these services, there needs to be billable services to support the 132 infrastructure. In some area close tracking of mobile devices will 133 be mandatory. In other device obfuscation to protect privacy and/or 134 safety will be the only life-enabling approach. 136 These conflicting requirements can be met with the Host Identity 137 Protocol (HIP), provided its Rendezvous Server service is scaleable 138 and manageable. Providers of RVS will need both a viable and 139 scaleable business model. 141 3.2. Semi-permanency of Identities 143 A device Identity has some degree of permanency. A device creates 144 its identity and registers it to some 3rd-party that will assert a 145 level of trust for that identity. A device may have multiple 146 identities to use in different contexts, and it may deprecate an 147 identity for any number of reasons. The asserting 3rd-party may 148 withdraw its assertion of an identity for any number of reasons. An 149 identity system needs to facilitate all of this. 151 3.3. Managing a large flat address space 153 For HIP to be successfully used in large mobile networks, it must 154 support an Identity per device, or at least 10 billion Identities. 155 Perhaps a Distributed Hash Table [I-D.irtf-hiprg-dht] can scale this 156 large. There is still the operational challenges in establishing 157 such a world-wide DHT implementation and how RVS [RFC8004] works with 158 such a large population. There is also the challenge of how to turn 159 this into a viable business for the Mobile Network Providers. 161 Even though the probability of collisions with 7B HITs (one HIT per 162 person) in a 96 bit flat address space is 3.9E-10, it is still real. 163 How are collisions managed? It is also possible that weak key 164 uniqueness, as has been shown in deployed TLS certificates, results 165 in a much greater probability of collisions. Thus resolution of 166 collisions needs to be 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 0.1.2.1.0.0.0.hhit.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 [RFC8003]. The client either uses an X.509 354 certificate [RFC8002], or use a PSK, as defined in Appendix A of HIP- 355 DEX [I-D.ietf-hip-dex], to validate the registration. 357 The Registration should include additional client information. This 358 information may be contained within the X.509 certificate and/or is 359 carried in the CLIENT_INFO parameter, see Section 5.2. The Registrar 360 can include its requirements in the R1 packet, and the client provide 361 its information in the I2 packet. This parameter may be encrypted 362 within the ENCRYPTED parameter. If the CLIENT_INFO contains Personal 363 Identifying Information (PII), then it MUST be placed into the 364 ENCRYPTED parameter. 366 The content and internal format of the CLIENT_INFO parameter is set 367 by the HDA's policy and is outside the scope of this document. 368 Examples of client information can by phone number, IMEI, and ICCID. 370 6.1. Hierarchical HIT Registration using X.509 Certificates 372 This requires the HIP client to possess a client certificate trusted 373 by the HDA/Registrar. Registration will either succeed or fail. 375 6.2. Hierarchical HIT Registration using a PSK 377 This requires the HIP client and the HDA/Registrar to share a PSK. 378 The PSK may already exist prior to starting the registration and just 379 be used within the registration. A PSK out-of-band exchange may be 380 triggered by performing the registration without any authentication. 382 If no client authentication is included in the I2 packet, the 383 registration fails with "No Authentication provided". If the I2 384 packet included the proper HDA required client information, the HDA 385 can use it to set up a side channel for an out-of-band delivery of a 386 PSK. And example of this would be to send an SMS message with the 387 PSK. Once the client possesses the PSK, it can rerun the 388 registration at which point the HI and HIT duplicate checks are 389 performed. 391 6.3. Hierarchical HIT Registration Type 393 The Registration Type used in the REG_REQUEST is: 395 Number Registration Type 396 ------ ----------------- 397 2 HIT Registration 399 6.4. Hierarchical HIT Registration Failure Type 401 The Registration may fail. In fact, with PSK, this may be the 402 response to expect an SMS message with the PSK to use in a second 403 registration request. Failure Types used in the REG_FAIL are: 405 Failure Type Reason 406 ------------ ----------------------- 407 [TBD-IANA] Hierarchical HIT Already Registered 408 [TBD-IANA] HI Already Registered 409 [TBD-IANA] Previously Registered HI with different device information 410 [TBD-IANA] No Authentication provided 411 [TBD-IANA] Invalid Authentication 412 [TBD-IANA] Invalid Authentication, new PSK sent via SMS 414 6.5. Registration failure behavior 416 If the failure type is "Hierarchical HIT Already Registered", the 417 client's HI is hashing to an existing HIT and must generate a new HI 418 and hierarchical HIT and reregister. If the failure is "HI Already 419 Registered", the client should assume it is registered. If the 420 failure is "Previously Registered HI with different device 421 information", either the client managed to generate a duplicate HI, 422 probably indicating a weak key generation algorithm, or the client 423 was previously registered on a different device. Resolving this 424 conflict will be left to the HDA's policy. 426 6.5.1. Example of a simple HDA policy 428 A simple HDA policy would be to require the device to generate a new 429 HI and thus HHIT and try registration again. The HDA policy may also 430 provide a URL for "Previous Registration Resolution". This contact 431 is primarily to assist a device that was registered, but had some 432 local failure resulting in a new registration attempt. 434 7. Using hierarchical HITs 436 All HIP clients with hierarchical HITs maintain an RVS connection 437 with their HDA's RVS server(s). How the HDA scales this service up 438 to a potential population in the millions is out of scope of this 439 document. Lifetime management of these connections is also out of 440 scope. 442 One approach an HDA can use to address the scaling challenge is to 443 add an internal level of hierarchy to assign a set number of devices 444 per RVS server. 446 Peering agreements between HDAs would allow for geographically close 447 RVS to a device. This may reduce the latency for use of a device's 448 current RVS. This is a subject of another document. 450 7.1. Contacting a HIP client 452 A service Initiator uses some service to discover the HIT of the 453 service Responder. The Initiator uses the hierarchical information 454 in the HIT to find the Responder's RVS. A trusted RVS discover 455 method could use the DNS PTR to RVS as shown in Section 4.1.3. An I1 456 is sent to that RVS which forwards it to the Responder. 458 The potential Responder uses the HIT in the I1 to query the 459 Initiator's RVS about the Initiator. The nature of information, and 460 method of communication are determined by the Initiator's HDA and the 461 Responder's (and or HDA's) relationship with it. Based on the 462 Responder's local policy, this information will be used to determine 463 if the contact is to be accepted. If accepted, the Responder may 464 proceed sending an R1 to the Initiator. It may alternatively 465 initiate some non-HIP process. 467 It should be noted that this R1 may contain a REG_INFO list for the 468 Initiator to validate that the Responder does offer the desired 469 service. 471 7.2. Defense against fraudulent HITs 473 Both the Initiator and Responder MAY validate a peer host as a 474 defense against a second pre-image attack on the HHIT. This may 475 occur via a CERT [RFC8002] in R1 or I2. It may be through a back end 476 process associated with the R1 or I2 validation to look up the HHIT 477 and retrieve the registered HI. 479 8. IANA Considerations 481 IANA will need to make the following changes to the "Host Identity 482 Protocol (HIP) Parameters" registries: 484 HIT Suite ID: This document defines the new HIT Suite "Hierarchy 485 with ECDSA/SHA256" (see Section 5.1). 487 CLIENT_INFO: This document defines the new CLIENT_INFO parameter 488 (see Section 5.2). The parameter value will be assigned by IANA. 490 Reg Type: This document defines the new Registration Type for the 491 REG_REQUEST parameter "HIT Registration" (see Section 6.3). 493 Reg Fail: This document defines the new Failure Types for the 494 REG_FAIL parameter (see Section 6.4). 496 9. RAA Management Organization Considerations 498 Introducing the RAA management organization may be the largest hurdle 499 for hierarchical HITs. Thus it would be best if this were adopted by 500 an organization already in the business of allocating numbers within 501 either the Internet or the Mobile, cellular, infrastructure. 503 One consideration would be to reserve the first N RAA values to map 504 to the existing DNS TLDs. For example, these TLDs can be organized 505 in an ascending order and numbered accordingly. Thus the 2 character 506 TLDs will be a lower number than the 3 character TLDs. After that, 507 it could be a first come, first numbered assignment process. 509 10. Security Considerations 511 There are potential risks with the hierarchical HIT, the Registry 512 service, and the discovery of potential peer hosts using its 513 hierarchical HIT. 515 A 64 bit hash space presents a real risk of second pre-image attacks. 516 The HHIT Registry services effectively block attempts to "take over" 517 a HHIT. It does not stop a rogue attempting to impersonate a known 518 HHIT. This attack can be mitigated by the Responder using DNS to 519 find the HI for the HHIT or the RVS for the HHIT that then provides 520 the registered HI. 522 The two risks with hierarchical HITs are the use of an invalid HID 523 and forced HIT collisions. The use of the "hhit.arpa." DNS zone is 524 a strong protection against invalid HIDs. Querying an HDA's RVS for 525 a HIT under the HDA protects against talking to unregistered clients. 526 The Registry service has direct protection against forced or 527 accidental HIT hash collisions. 529 By using the HIP Registration Extension, the Registry service is 530 protected from direct attacks. This service does rely on either the 531 integrity of a PKI service or an out-of-band PSK delivery process. 532 Thus the risk to the Registry service is highly related to the trust 533 in these authentication setup services. Further, the duplicate HI 534 resolution process may require human interaction with related social 535 engineering risks. 537 Finally the peer host discovery process relies on trusting the 538 finding the proper HDA for the host and its forwarding the I1 to the 539 proper Responder. A rogue RVS, impersonating the RVS for the HIT, 540 could redirect the I1 to a client that has forced a collision with 541 the HIT and the Initiator would be none the wiser. The only defense 542 against this is if the Initiator has some other source for the 543 Responder HI and validate the HI in the R1. 545 10.1. Privacy Concerns 547 Mobile-privacy-attack [I-D.moskowitz-mobile-privacy-attack] details 548 how Eve can follow a communication between two mobile peers using the 549 session Identifiers and deep knowledge about those Identifiers gained 550 by hacking servers that log PII related to the Identifiers. 552 Hierarchical HITs not only does not mitigate this attack, it can 553 actually aggravate it by supplying the HDA where the HHIT is 554 registered. 556 A HIP Privacy Enhanced Base Exchange, to be defined in a separate 557 draft, along with a Privacy Enhanced ESP tunnel, can be used to hide 558 all the HIP and ESP Identifiers from Eve. 560 11. Acknowledgments 562 Sue Hares of Huawei contributed to the clarity in this document. 564 12. References 566 12.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, 570 DOI 10.17487/RFC2119, March 1997, . 573 12.2. Informative References 575 [I-D.ietf-hip-dex] 576 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 577 draft-ietf-hip-dex-06 (work in progress), December 2017. 579 [I-D.irtf-hiprg-dht] 580 Ahrenholz, J., "Host Identity Protocol Distributed Hash 581 Table Interface", draft-irtf-hiprg-dht-05 (work in 582 progress), December 2011. 584 [I-D.moskowitz-mobile-privacy-attack] 585 Moskowitz, R., "An Attack on Privacy in Mobile Devices", 586 draft-moskowitz-mobile-privacy-attack-01 (work in 587 progress), November 2017. 589 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 590 Routable Cryptographic Hash Identifiers Version 2 591 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 592 2014, . 594 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 595 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 596 RFC 7401, DOI 10.17487/RFC7401, April 2015, 597 . 599 [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol 600 Certificates", RFC 8002, DOI 10.17487/RFC8002, October 601 2016, . 603 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 604 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 605 October 2016, . 607 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 608 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 609 October 2016, . 611 Appendix A. Calculating Collision Probabilities 613 The accepted formula for calculating the probability of a collision 614 is: 616 p = 1 - e^{-k^2/(2n)} 618 P Collision Probability 619 n Total possible population 620 k Actual population 622 Authors' Addresses 624 Robert Moskowitz 625 Huawei 626 Oak Park, MI 48237 627 USA 629 Email: rgm@labs.htt-consult.com 631 Xiaohu Xu 632 Huawei 633 Huawei Bld, No.156 Beiqing Rd. 634 Beijing, Hai-Dian District 100095 635 China 637 Email: xuxiaohu@huawei.com 639 Bingyang Liu 640 Huawei 641 Huawei Bld, No.156 Beiqing Rd. 642 Beijing, Hai-Dian District 100095 643 China 645 Email: liubingyang@huawei.com