Internet DRAFT - draft-moskowitz-hip-based-5gpp-ip-mobility

draft-moskowitz-hip-based-5gpp-ip-mobility







HIP                                                         R. Moskowitz
Internet-Draft                                                     X. Xu
Intended status: Standards Track                                  B. Liu
Expires: December 28, 2017                                        Huawei
                                                           June 26, 2017


        HIP Enabled ID/Loc separation for fast 5GPP IP mobility
           draft-moskowitz-hip-based-5gpp-ip-mobility-02.txt

Abstract

   HIP [RFC7401] stands alone in providing a secure Endpoint ID for
   decoupling the Internetworking and Transport protocol layers.  The
   addition of a secure rendezvous service to facilitate mobility will
   form the cornerstones for this 5GPP mobility technology.  This
   document will describe complete mobility environment and the
   additional components needed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 28, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Moskowitz, et al.       Expires December 28, 2017               [Page 1]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The components to a HIP-based Mobile world  . . . . . . . . .   3
     3.1.  Service to HIT mapping by device/owner name . . . . . . .   3
     3.2.  HIT to IP mapping service . . . . . . . . . . . . . . . .   3
     3.3.  Shortest Path Routing support . . . . . . . . . . . . . .   4
   4.  Providing services to meet mobility needs . . . . . . . . . .   4
     4.1.  Scaleable HITs  . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Additional services associated with the HDA RVS . . . . .   4
     4.3.  Preparing to use an HHIT  . . . . . . . . . . . . . . . .   5
     4.4.  Protecting privacy of an HHIT . . . . . . . . . . . . . .   5
     4.5.  Contacting a device based on its HHIT . . . . . . . . . .   5
     4.6.  Intra-HDA peering agreements  . . . . . . . . . . . . . .   5
     4.7.  Maintaining the HIP session through all mobility events .   6
   5.  HIP proxies to Legacy (non-HIP) hosts . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Calculating Collision Probabilities  . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   IP mobility in the next generation cellular networks will demand
   shortest path routing, transportation of data secure from a laundry
   list of attacks, minimal cost infrastructure, and a viable business
   model for the providers of the 5GPP infrastructure.

   Infrastructure costs for the 5GPP network come in many forms.  Costs
   can arise from the cost to support network services, or costs to
   encapsulate data, or network over-provisioning costs to reduce
   network delays.  At the heart of all the 3GPP mobility costs is the
   effort to reduce reconnection delays for IP packets so improve users
   experience.  The preferred solution for the 5GPP infrastructure will
   offer the best possible user experience at the best delivery price
   point.





Moskowitz, et al.       Expires December 28, 2017               [Page 2]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   HIP, with some important infrastructure enhancements can deliver on
   these requirements.  This document will detail the infrastructure
   environment needed along with how all the HIP pieces will fit
   together.

   Further, HIP multihoming support can facilitate a "Make then Break"
   connectivity model that would add to the user experience and
   facilitate network providers offloading of traffic to more cost-
   effective connections.

   Finally, HIP mobility is not an overlay solution to mobility.
   Infrastructure implications are principally requirements for RVS, HIP
   Proxies (for legacy host mobility access), and potentially HIP NAT
   traversal services.

2.  Terms and Definitions

2.1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Definitions

   X: X.

3.  The components to a HIP-based Mobile world

   Three fundamental components lay the foundation of a HIP-based mobile
   world.  These need extreme scalability at numbers easily ranging from
   10 billion to 1 trillion entries.  Many portions can be fragmented.
   That is there is needed fore-knowledge to gain entry.

3.1.  Service to HIT mapping by device/owner name

   "I wish to make a video call to Alice" query to a video call service
   should return Alice's HIT.  Alice could register her HIT with the
   video calling service mapping by proving ownership of the HIT (via a
   HIP registration exchange).  Which is a separate exercise beyond the
   basic scope of this service.

3.2.  HIT to IP mapping service

   The HIT is then mapped to Alice's device's current IP address for
   setting up the HIP Security Association and the video stream
   connection between the IP addresses, mapped to the HITs rather than
   the location IP addresses.



Moskowitz, et al.       Expires December 28, 2017               [Page 3]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   Even at a later time, a cached HIT can be used to discover Alice's
   device's current IP address.

   For a multihomed device, all addresses can be evaluated, perhaps by
   an analytics engine associated with the device's RVS for best route
   selection.

3.3.  Shortest Path Routing support

   Both Bob and Alice are very active people and their devices are
   constantly moving.  However they wander after starting the session,
   their devices need to stay in contact with each other.  This needs
   good performance for when the are in the same city or across the
   world.

   For multihomed devices, all the addresses should be evaluated and the
   best route selected.

4.  Providing services to meet mobility needs

4.1.  Scaleable HITs

   HITs as defined in RFC7401 [RFC7401] have a 96 bit flat address
   space.  A 1 trillion deployment HITs would have a 0.0006% probability
   of a collision Appendix A.  However, it is probably significantly
   worst than this due to historical problems with 'good' random number
   generators or asymmetric key pairs.  Selecting a HIT that will not
   collide with a future communication peer is an effort in futility.
   Hierarchical HITs [I-D.moskowitz-hierarchical-hip] provides a
   manageable approach to HITs and supplies the basics for a viable
   business model for registering ownership of a HIT.

   Alice selects a Hierarchical HIT Domain Authority (HDA) for her
   device A.  This may be a different HDA than her device Q.  She agrees
   to the policy of use by that HDA and follows their instructions to
   register the HHIT for the device.  The HDA insures there is no
   authorized collision with her selected HHIT.  She then publishes that
   HHIT for the services she wishes to be publicly known.  Or she can
   just share her HHIT with friends and/or colleagues.  At any time she
   may withdraw that HHIT.  If she is found in violation of the HDA's
   policy, it can unregister her device.

4.2.  Additional services associated with the HDA RVS

   The RVS mechanism provides a rich environment to add additional
   services to enhance the overall performance of mobility.





Moskowitz, et al.       Expires December 28, 2017               [Page 4]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   For example, where a device registers multiple locators on RVS
   registration, an analytics engine can assess connection costs for
   each HIP connection request (I1 or UPDATE) received.

4.3.  Preparing to use an HHIT

   HHIT strongly recommends using the HIP RVS.  Even a truly stationary
   HIP-enabled server should use it and use the corresponding 'HIP fast
   Mobility' to stay connected with its mobile communication partners.
   An RVS could be used for active load balancing across servers with
   different HITs.

   All devices mobile MUST maintain an active RVS connection.  This is
   required even if device Q never publishes any services but always
   initiate the session.  Q still needs RVS to support fast mobility.
   Without it the recovery from a double-jump would be left up to Q with
   no possible successful mobility update by its HIP peer until Q
   completes its mobility update.

4.4.  Protecting privacy of an HHIT

   An HDA may have a policy to only confirm the validity of a HHIT to HI
   mapping on receipt of an I2 or R2 packet from the recipient of that
   packet.  This shows that the HIP device was actively connecting to
   the peer requesting validation and already has a HIT to HI pairing.
   This protects against robots and the like trolling for valid HHITs.

   A device can have as many HHITs as it wishes, registering each with a
   different HDA, if desired.  It can withdraw a HHIT and register a new
   one, provided the HDA permits this action.  This is commonly done for
   identity privacy reasons.  If Bob wants some medical advice, he can
   have his device register a new HHIT for this research then withdraw
   it when finished.

4.5.  Contacting a device based on its HHIT

   There can be a direct DNS mapping of the HDA within the HHIT to that
   HDA's RVS.  This provides the access to the device where ever it may
   be.

4.6.  Intra-HDA peering agreements

   A HIP Client to RVS connection that spans the globe will work, as
   will the mobility updates.  But this may not be the most efficient
   approach.  An HDA may globally diversify its RVS and use DNS to
   direct the client to the 'nearest' RVS.





Moskowitz, et al.       Expires December 28, 2017               [Page 5]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   Alternatively, two HDAs could maintain a peering arrangement.  The
   mechanism by which a client selects the 'best' HDA peer
   geographically and is contacted through that RVS rather than the HHIT
   native RVS is a future work item.

4.7.  Maintaining the HIP session through all mobility events

   With each peer in a HIP Security Association maintaining an active
   connection to their HHIT RVS, the HIP fast mobility mechanism ensures
   SA remapping to any location changes in a timely manner.

5.  HIP proxies to Legacy (non-HIP) hosts

   A HIP mobile host can use non-HIP connections to legacy, static
   servers.  This approach would burden the communications with
   reconnects.  5GPP may well have a significantly higher occurrence of
   IP address changes than 4GPP.  This would benefit from a HIP mobility
   enabled mechanism provided in HIP proxy solutions
   [I-D.irtf-hiprg-proxies].

6.  IANA Considerations

   There are no IANA considerations for this document.

7.  Security Considerations

   TBD

8.  Acknowledgments

   Sue Hares of Huawei contributed to the clarity in this document.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

9.2.  Informative References

   [I-D.irtf-hiprg-proxies]
              Zhang, D., Xu, X., Yao, J., and Z. Cao, "Overview of HIP
              Proxy Scenarios and Solutions", draft-irtf-hiprg-
              proxies-05 (work in progress), March 2012.




Moskowitz, et al.       Expires December 28, 2017               [Page 6]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   [I-D.moskowitz-hierarchical-hip]
              Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2",
              draft-moskowitz-hierarchical-hip-03 (work in progress),
              June 2017.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <http://www.rfc-editor.org/info/rfc7401>.

Appendix A.  Calculating Collision Probabilities

   The accepted formula for calculating the probability of a collision
   is:


           p = 1 - e^{-k^2/(2n)}


           P       Collision Probability
           n       Total possible population
           k       Actual population



Authors' Addresses

   Robert Moskowitz
   Huawei
   Oak Park, MI  48237
   USA

   Email: rgm@labs.htt-consult.com


   Xiaohu Xu
   Huawei
   Huawei Bld, No.156 Beiqing Rd.
   Beijing, Hai-Dian District  100095
   China

   Email: xuxiaohu@huawei.com









Moskowitz, et al.       Expires December 28, 2017               [Page 7]

Internet-Draft        HIP enabled 5GPP IP Mobility             June 2017


   Bingyang Liu
   Huawei
   Huawei Bld, No.156 Beiqing Rd.
   Beijing, Hai-Dian District  100095
   China

   Email: xuxiaohu@huawei.com












































Moskowitz, et al.       Expires December 28, 2017               [Page 8]