--- 1/draft-ietf-dmm-ondemand-mobility-16.txt 2019-02-22 07:13:27.434461967 -0800 +++ 2/draft-ietf-dmm-ondemand-mobility-17.txt 2019-02-22 07:13:27.478463025 -0800 @@ -1,98 +1,93 @@ DMM Working Group A. Yegin Internet-Draft Actility Intended status: Informational D. Moses -Expires: August 12, 2019 Intel - K. Kweon - J. Lee - J. Park - Samsung +Expires: August 26, 2019 Intel S. Jeon Sungkyunkwan University - February 8, 2019 + February 22, 2019 On Demand Mobility Management - draft-ietf-dmm-ondemand-mobility-16 + draft-ietf-dmm-ondemand-mobility-17 Abstract Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running - on the host yields inefficiencies, as described in section 4 of - [RFC7333]. This document defines a new concep of enabling - applications to influence the network's mobility services (session - continuity and/or IP address reachability) on a per-Socket basis, and - suggests extensions to the networking stack's API to accomodate this - concept. + on the host yields inefficiencies, as described in [RFC7333]. This + document defines a new concep of enabling applications to influence + the network's mobility services (session continuity and/or IP address + reachability) on a per-Socket basis, and suggests extensions to the + networking stack's API to accomodate this concept. 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 https://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 August 12, 2019. + This Internet-Draft will expire on August 26, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. High-level Description . . . . . . . . . . . . . . . . . 4 3.2. Types of IP Addresses . . . . . . . . . . . . . . . . . . 5 - 3.3. Granularity of Selection . . . . . . . . . . . . . . . . 7 - 3.4. On Demand Nature . . . . . . . . . . . . . . . . . . . . 7 - 3.5. Conveying the Desired Address Type . . . . . . . . . . . 8 - 4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Pseudo-code example . . . . . . . . . . . . . . . . . . . 9 - 4.2. Message Flow example . . . . . . . . . . . . . . . . . . 11 + 3.3. Granularity of Selection . . . . . . . . . . . . . . . . 6 + 3.4. On Demand Nature . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Conveying the Desired Address Type . . . . . . . . . . . 7 + 4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Pseudo-code example . . . . . . . . . . . . . . . . . . . 8 + 4.2. Message Flow example . . . . . . . . . . . . . . . . . . 10 5. Backwards Compatibility Considerations . . . . . . . . . . . 12 5.1. Applications . . . . . . . . . . . . . . . . . . . . . . 12 - 5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 13 + 5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 12 5.3. Network Infrastructure . . . . . . . . . . . . . . . . . 13 5.4. Merging this work with RFC5014 . . . . . . . . . . . . . 13 - 6. Summary of New Definitions . . . . . . . . . . . . . . . . . 14 - 6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6. Summary of New Definitions . . . . . . . . . . . . . . . . . 13 + 6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 11.2. Informative References . . . . . . . . . . . . . . . . . 16 + 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the following two attributes are defined for IP service provided to mobile hosts: - Session Continuity @@ -115,38 +110,38 @@ essential for mobile hosts to use specific/published IP addresses. Mobile IP is designed to provide both session continuity and IP address reachability to mobile hosts. Architectures utilizing these protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host attached to the compliant networks can enjoy these benefits. Any application running on these mobile hosts is subjected to the same treatment with respect to session continuity and IP address reachability. - In reality not every application may need these benefits. IP address - reachability is required for applications running as servers (e.g., a - web server running on the mobile host). But, a typical client - application (e.g., web browser) does not necessarily require IP - address reachability. Similarly, session continuity is not required - for all types of applications either. Applications performing brief - communication (e.g., text messaging) can survive without having - session continuity support. - Achieving session continuity and IP address reachability with Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [RFC7333]. Therefore, session continuity and IP address reachability SHOULD be provided only when necessary. + In reality not every application may need these benefits. IP address + reachability is required for applications running as servers (e.g., a + web server running on the mobile host). But, a typical client + application (e.g., web browser) does not necessarily require IP + address reachability. Similarly, session continuity is not required + for all types of applications either. Applications performing brief + communication (e.g., text messaging) can survive without having + session continuity support. + Furthermore, when an application needs session continuity, it may be able to satisfy that need by using a solution above the IP layer, such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application- layer mobility solution. These higher-layer solutions are not subject to the same issues that arise with the use of Mobile IP since they can utilize the most direct data path between the end-points. But, if Mobile IP is being applied to the mobile host, the higher- layer protocols are rendered useless because their operation is inhibited by Mobile IP. Since Mobile IP ensures that the IP address of the mobile host remains fixed (despite the location and movement @@ -190,22 +185,22 @@ - The network stack sends a request to the network for a new source IP prefix that is associated with the desired mobility service. - The network responds with the suitable allocated source IP prefix (or responds with a failure indication). - If the suitable source IP prefix was allocates, the network stack constructs a source IP address and provides it to the application. - This document specifies the new address types (associated with - mobility services) and details the interaction between the + This document specifies the new address types associated with + mobility services and details the interaction between the applications and the network stack steps. It uses the Socket interface as an example for an API between applications and the network stack. Other steps are outside the scope of this document. 3.2. Types of IP Addresses Four types of IP addresses are defined with respect to mobility management. - Fixed IP Address @@ -411,21 +406,22 @@ // ... } // if socket creation failed else { // Socket creation is successful // The application cannot connect yet, since it wants to use // a Session-Lasting source IP address It needs to request // the Session-Lasting source IP before connecting if (setsc(s, &sourceAddress, &sc_type)) == 0){ // setting session continuity to Session Lasting is // Successful. sourceAddress now contains the Session- - // LAsting source IP address + // Lasting source IP address + // Bind to that source IP address sourceInfo.sin6_family = AF_INET6 ; sourceInfo.sin6_port = 0 // let the stack choose the port sourceInfo.sin6_address = sourceAddress ; // Use the source address that was // generated by the setsc() call if (bind(s, &sourceInfo, sizeof(sourceInfo))==0){ // Set the desired server's information for connect() serverInfo.sin6_family = AF_INET6 ; serverInfo.sin6_port = SERVER_PORT_NUM ; @@ -549,32 +546,32 @@ - The IP stack in the mobile host - The network infrastructure 5.1. Applications Legacy applications that do not support the On-Demand functionality will use the legacy API and will not be able to take advantage of the On-Demand Mobility feature. - Applications using the new On-Demand functionality MUST be aware that - they may be executed in legacy environments that do not support it. - Such environments may include a legacy IP stack on the mobile host, - legacy network infrastructure, or both. In either case, the API will - return an error code and the invoking applications may just give up - and use legacy calls. + Applications using the new On-Demand functionality should be aware + that they may be executed in legacy environments that do not support + it. Such environments may include a legacy IP stack on the mobile + host, legacy network infrastructure, or both. In either case, the + API will return an error code and the invoking applications may just + give up and use legacy calls. 5.2. IP Stack in the Mobile Host - New IP stacks MUST continue to support all legacy operations. If an - application does not use On-Demand functionality, the IP stack MUST - respond in a legacy manner. + New IP stacks (that implement On Demand functionality) MUST continue + to support all legacy operations. If an application does not use On- + Demand functionality, the IP stack MUST respond in a legacy manner. If the network infrastructure supports On-Demand functionality, the IP stack SHOULD follow the application request: If the application requests a specific address type, the stack SHOULD forward this request to the network. If the application does not request an address type, the IP stack MUST NOT request an address type and leave it to the network's default behavior to choose the type of the allocated IP prefix. If an IP prefix was already allocated to the host, the IP stack uses it and may not request a new one from the network. @@ -647,33 +644,72 @@ result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below), setsc() MAY return immediately with the constructed IP address and will not block the thread. 6.2. New Flags The following flag is added to the list of flags in the IPV6_ADDR_PREFERENCE option at the IPPROTO6 level: IPV6_REQUIRE_SRC_ON_NET - set IP stack address allocation behavior + If set, the IP stack will request a new IPv6 prefix of the desired type from the current serving network and configure a new source IP address. If reset, the IP stack will use a preconfigured one if it exists. If there is no preconfigured IP address of the desired type, a new prefix will be requested and used for creating the IP address. 7. Security Considerations - The setting of certain IP address type on a given socket may be - restricted to privileged applications. For example, a Fixed IP - Address may be provided as a premium service and only certain - applications may be allowed to use them. Setting and enforcement of - such privileges are outside the scope of this document. + The different service types (session continuity types and address + reachability) associated with the allocated IP address types, may be + associated with different costs. The cost to the operator for + enabling a type of service, and the cost to applications using a + selected service. A malicious application may use these to generate + extra billing of a mobile subscriber, and/or impose costly services + on the mobile operator. When costly services are limited, malicious + applications may exhaust them, preventing other applications on the + same mobile host from being able to use them. + + Mobile hosts that enables such service options, should provide + capabilities for ensuring that only authorized applications can use + the costly (or limited) service types. + + The ability to select service types requires the exchange of the + association of source IP prefixes and their corresponding service + types, between the mobile host and mobile network. Exposing these + associations may provide information to passive attackers even if the + traffic that is used with these addressed is encrypted. + + To avoid profiling an application according to the type of IP + addresses, it is expected that prefixes provided by the mobile + operator are associated to various type of addresses over time. As a + result, the type of address could not be associated to the prefix, + making application profiling based on the type of address harder. + + The application or the OS should ensure that IP addresses regularly + change to limit IP tracking by a passive observer. The application + should regularly set the On Demand flag. The application should be + able to ensure that session lasting IP addresses are regularly + changed by setting a lifetime for example handled by the application. + In addition, the application should consider the use of graceful + replacement IP addresses. + + Similarly, the OS may also associated IP addresses with a lifetime. + Upon receiving a request for a given type of IP address, after some + time, the OS should request a new address to the network even if it + already has one IP address available with the requested type. This + includes any type of IP address. IP addresses of type graceful + replacement or non persistent should be regularly renewed by the OS. + + The lifetime of an IP address may be expressed in number of seconds + or in number of bytes sent through this IP address. 8. IANA Considerations This document has no IANA considerations. 9. Contributors This document was merged with [I-D.sijeon-dmm-use-cases-api-source]. We would like to acknowledge the contribution of the following people to that document as well: @@ -686,24 +722,25 @@ Soongsil University, Korea Email: younghak@ssu.ac.kr John Kaippallimalil Huawei, USA Email: john.kaippallimalil@huawei.com 10. Acknowledgements We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni - Korhonen, Sri Gundavelli, Dave Dolson and Lorenzo Colitti for their - valuable comments and suggestions on this work. + Korhonen, Sri Gundavelli, Dave Dolson Lorenzo Colitti and Daniel + Migault for their valuable comments and suggestions on this work. 11. References + 11.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, . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, @@ -764,36 +800,16 @@ Email: alper.yegin@actility.com Danny Moses Intel Corporation Petah Tikva Israel Email: danny.moses@intel.com - Kisuk Kweon - Samsung - Suwon - South Korea - - Email: kisuk.kweon@samsung.com - - Jinsung Lee - Samsung - Suwon - South Korea - - Email: js81.lee@samsung.com - Jungshin Park - Samsung - Suwon - South Korea - - Email: shin02.park@samsung.com - Seil Jeon Sungkyunkwan University Suwon South Korea Email: seiljeon@skku.edu