idnits 2.17.1 draft-moskowitz-hip-based-5gpp-ip-mobility-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7401]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2017) is 2493 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) == Outdated reference: A later version (-06) exists of draft-moskowitz-hierarchical-hip-03 Summary: 1 error (**), 0 flaws (~~), 2 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: December 28, 2017 Huawei 6 June 26, 2017 8 HIP Enabled ID/Loc separation for fast 5GPP IP mobility 9 draft-moskowitz-hip-based-5gpp-ip-mobility-02.txt 11 Abstract 13 HIP [RFC7401] stands alone in providing a secure Endpoint ID for 14 decoupling the Internetworking and Transport protocol layers. The 15 addition of a secure rendezvous service to facilitate mobility will 16 form the cornerstones for this 5GPP mobility technology. This 17 document will describe complete mobility environment and the 18 additional components needed. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 28, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 57 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The components to a HIP-based Mobile world . . . . . . . . . 3 59 3.1. Service to HIT mapping by device/owner name . . . . . . . 3 60 3.2. HIT to IP mapping service . . . . . . . . . . . . . . . . 3 61 3.3. Shortest Path Routing support . . . . . . . . . . . . . . 4 62 4. Providing services to meet mobility needs . . . . . . . . . . 4 63 4.1. Scaleable HITs . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Additional services associated with the HDA RVS . . . . . 4 65 4.3. Preparing to use an HHIT . . . . . . . . . . . . . . . . 5 66 4.4. Protecting privacy of an HHIT . . . . . . . . . . . . . . 5 67 4.5. Contacting a device based on its HHIT . . . . . . . . . . 5 68 4.6. Intra-HDA peering agreements . . . . . . . . . . . . . . 5 69 4.7. Maintaining the HIP session through all mobility events . 6 70 5. HIP proxies to Legacy (non-HIP) hosts . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 9.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Appendix A. Calculating Collision Probabilities . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 IP mobility in the next generation cellular networks will demand 83 shortest path routing, transportation of data secure from a laundry 84 list of attacks, minimal cost infrastructure, and a viable business 85 model for the providers of the 5GPP infrastructure. 87 Infrastructure costs for the 5GPP network come in many forms. Costs 88 can arise from the cost to support network services, or costs to 89 encapsulate data, or network over-provisioning costs to reduce 90 network delays. At the heart of all the 3GPP mobility costs is the 91 effort to reduce reconnection delays for IP packets so improve users 92 experience. The preferred solution for the 5GPP infrastructure will 93 offer the best possible user experience at the best delivery price 94 point. 96 HIP, with some important infrastructure enhancements can deliver on 97 these requirements. This document will detail the infrastructure 98 environment needed along with how all the HIP pieces will fit 99 together. 101 Further, HIP multihoming support can facilitate a "Make then Break" 102 connectivity model that would add to the user experience and 103 facilitate network providers offloading of traffic to more cost- 104 effective connections. 106 Finally, HIP mobility is not an overlay solution to mobility. 107 Infrastructure implications are principally requirements for RVS, HIP 108 Proxies (for legacy host mobility access), and potentially HIP NAT 109 traversal services. 111 2. Terms and Definitions 113 2.1. Requirements Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2.2. Definitions 121 X: X. 123 3. The components to a HIP-based Mobile world 125 Three fundamental components lay the foundation of a HIP-based mobile 126 world. These need extreme scalability at numbers easily ranging from 127 10 billion to 1 trillion entries. Many portions can be fragmented. 128 That is there is needed fore-knowledge to gain entry. 130 3.1. Service to HIT mapping by device/owner name 132 "I wish to make a video call to Alice" query to a video call service 133 should return Alice's HIT. Alice could register her HIT with the 134 video calling service mapping by proving ownership of the HIT (via a 135 HIP registration exchange). Which is a separate exercise beyond the 136 basic scope of this service. 138 3.2. HIT to IP mapping service 140 The HIT is then mapped to Alice's device's current IP address for 141 setting up the HIP Security Association and the video stream 142 connection between the IP addresses, mapped to the HITs rather than 143 the location IP addresses. 145 Even at a later time, a cached HIT can be used to discover Alice's 146 device's current IP address. 148 For a multihomed device, all addresses can be evaluated, perhaps by 149 an analytics engine associated with the device's RVS for best route 150 selection. 152 3.3. Shortest Path Routing support 154 Both Bob and Alice are very active people and their devices are 155 constantly moving. However they wander after starting the session, 156 their devices need to stay in contact with each other. This needs 157 good performance for when the are in the same city or across the 158 world. 160 For multihomed devices, all the addresses should be evaluated and the 161 best route selected. 163 4. Providing services to meet mobility needs 165 4.1. Scaleable HITs 167 HITs as defined in RFC7401 [RFC7401] have a 96 bit flat address 168 space. A 1 trillion deployment HITs would have a 0.0006% probability 169 of a collision Appendix A. However, it is probably significantly 170 worst than this due to historical problems with 'good' random number 171 generators or asymmetric key pairs. Selecting a HIT that will not 172 collide with a future communication peer is an effort in futility. 173 Hierarchical HITs [I-D.moskowitz-hierarchical-hip] provides a 174 manageable approach to HITs and supplies the basics for a viable 175 business model for registering ownership of a HIT. 177 Alice selects a Hierarchical HIT Domain Authority (HDA) for her 178 device A. This may be a different HDA than her device Q. She agrees 179 to the policy of use by that HDA and follows their instructions to 180 register the HHIT for the device. The HDA insures there is no 181 authorized collision with her selected HHIT. She then publishes that 182 HHIT for the services she wishes to be publicly known. Or she can 183 just share her HHIT with friends and/or colleagues. At any time she 184 may withdraw that HHIT. If she is found in violation of the HDA's 185 policy, it can unregister her device. 187 4.2. Additional services associated with the HDA RVS 189 The RVS mechanism provides a rich environment to add additional 190 services to enhance the overall performance of mobility. 192 For example, where a device registers multiple locators on RVS 193 registration, an analytics engine can assess connection costs for 194 each HIP connection request (I1 or UPDATE) received. 196 4.3. Preparing to use an HHIT 198 HHIT strongly recommends using the HIP RVS. Even a truly stationary 199 HIP-enabled server should use it and use the corresponding 'HIP fast 200 Mobility' to stay connected with its mobile communication partners. 201 An RVS could be used for active load balancing across servers with 202 different HITs. 204 All devices mobile MUST maintain an active RVS connection. This is 205 required even if device Q never publishes any services but always 206 initiate the session. Q still needs RVS to support fast mobility. 207 Without it the recovery from a double-jump would be left up to Q with 208 no possible successful mobility update by its HIP peer until Q 209 completes its mobility update. 211 4.4. Protecting privacy of an HHIT 213 An HDA may have a policy to only confirm the validity of a HHIT to HI 214 mapping on receipt of an I2 or R2 packet from the recipient of that 215 packet. This shows that the HIP device was actively connecting to 216 the peer requesting validation and already has a HIT to HI pairing. 217 This protects against robots and the like trolling for valid HHITs. 219 A device can have as many HHITs as it wishes, registering each with a 220 different HDA, if desired. It can withdraw a HHIT and register a new 221 one, provided the HDA permits this action. This is commonly done for 222 identity privacy reasons. If Bob wants some medical advice, he can 223 have his device register a new HHIT for this research then withdraw 224 it when finished. 226 4.5. Contacting a device based on its HHIT 228 There can be a direct DNS mapping of the HDA within the HHIT to that 229 HDA's RVS. This provides the access to the device where ever it may 230 be. 232 4.6. Intra-HDA peering agreements 234 A HIP Client to RVS connection that spans the globe will work, as 235 will the mobility updates. But this may not be the most efficient 236 approach. An HDA may globally diversify its RVS and use DNS to 237 direct the client to the 'nearest' RVS. 239 Alternatively, two HDAs could maintain a peering arrangement. The 240 mechanism by which a client selects the 'best' HDA peer 241 geographically and is contacted through that RVS rather than the HHIT 242 native RVS is a future work item. 244 4.7. Maintaining the HIP session through all mobility events 246 With each peer in a HIP Security Association maintaining an active 247 connection to their HHIT RVS, the HIP fast mobility mechanism ensures 248 SA remapping to any location changes in a timely manner. 250 5. HIP proxies to Legacy (non-HIP) hosts 252 A HIP mobile host can use non-HIP connections to legacy, static 253 servers. This approach would burden the communications with 254 reconnects. 5GPP may well have a significantly higher occurrence of 255 IP address changes than 4GPP. This would benefit from a HIP mobility 256 enabled mechanism provided in HIP proxy solutions 257 [I-D.irtf-hiprg-proxies]. 259 6. IANA Considerations 261 There are no IANA considerations for this document. 263 7. Security Considerations 265 TBD 267 8. Acknowledgments 269 Sue Hares of Huawei contributed to the clarity in this document. 271 9. References 273 9.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 9.2. Informative References 282 [I-D.irtf-hiprg-proxies] 283 Zhang, D., Xu, X., Yao, J., and Z. Cao, "Overview of HIP 284 Proxy Scenarios and Solutions", draft-irtf-hiprg- 285 proxies-05 (work in progress), March 2012. 287 [I-D.moskowitz-hierarchical-hip] 288 Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2", 289 draft-moskowitz-hierarchical-hip-03 (work in progress), 290 June 2017. 292 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 293 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 294 RFC 7401, DOI 10.17487/RFC7401, April 2015, 295 . 297 Appendix A. Calculating Collision Probabilities 299 The accepted formula for calculating the probability of a collision 300 is: 302 p = 1 - e^{-k^2/(2n)} 304 P Collision Probability 305 n Total possible population 306 k Actual population 308 Authors' Addresses 310 Robert Moskowitz 311 Huawei 312 Oak Park, MI 48237 313 USA 315 Email: rgm@labs.htt-consult.com 317 Xiaohu Xu 318 Huawei 319 Huawei Bld, No.156 Beiqing Rd. 320 Beijing, Hai-Dian District 100095 321 China 323 Email: xuxiaohu@huawei.com 324 Bingyang Liu 325 Huawei 326 Huawei Bld, No.156 Beiqing Rd. 327 Beijing, Hai-Dian District 100095 328 China 330 Email: xuxiaohu@huawei.com