MIF WG H. Deng Internet-Draft China Mobile Intended status: Informational S. Krishnan Expires: January 16, 2013 Ericsson T. Lemon Nominum M. Wasserman Painless Security, LLC July 15, 2012 Guide for application developers on session continuity by using MIF API draft-deng-mif-api-session-continuity-guide-01 Abstract Today most smart terminals are equiped with multiple interfaces such as 3G/LTE and Wifi, users experience some application broken during switching interfaces. MIF API draft [I-D.ietf-mif-api-extension] has specified some API to announce interface on/off information to the applications. Once the application received those information, it can re-connect to the servers which could improve session continuity experience in some extent. Requirements Language 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]. 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 January 16, 2013. Copyright Notice Deng, et al. Expires January 16, 2013 [Page 1] Internet-Draft MIF API Session Continuity July 2012 Copyright (c) 2012 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related MIF API information . . . . . . . . . . . . . . . . . . 3 3. Using different source address to reconnect the server . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Deng, et al. Expires January 16, 2013 [Page 2] Internet-Draft MIF API Session Continuity July 2012 1. Introduction Most smart terminals today have both Wifi and 3G/LTE interfaces, and operators may charge differently for different connection which lead to user sometime switching their interface when the terminals are in the different network coverage. When the user switched from 3G/LTE to wifi or vice versa, the applications sitting in the terminal are not awared of this change may experience of broken. MIF API draft [I-D.ietf-mif-api-extension] has specified an API interface, there are some API related to interface status information. if the application developers are awared of those information, then they can develop the application to follow those behavior. this document try to write a guidance about how the application developer use MIF API information to guarantee the application session continuity by changing the source address. 2. Related MIF API information MIF API draft [I-D.ietf-mif-api-extension] defined couple of MIF Messages which is related to whether interface is available or not in section 3.5.1 and 3.5.4 by the message of Announce Interfaces and No Interface Announcement, same as the address information in section 3.5.12 and 3.5.14. Both interface and address information could be used by the application to take use of the avilablility of the second interface. 3. Using different source address to reconnect the server The Internet application client usually setup the connection with the server, then trying to keep the connection as long as it can. It works reasonable when the host has only one interface. Once the smart terminal which has both 3G/LTE and WLAN interface. The price and the connection speed are different, so for the consideration of the user, they would prefer to change another cheaper and faster connection, for example from 3G/LTE to WLAN, normally the smart terminal will get different IP address, DNS server and default gateway. The application will normally break after the original interface switched off. The realtime application such as game, video, and voice will break. The HTTP application like browser will stop download the content, and the user have to re-fresh the explorer again. if the application developer understand this circumstance, and there is MIF API avilable by different representation based on different mobile OS. then the application could be designed reconnect the Deng, et al. Expires January 16, 2013 [Page 3] Internet-Draft MIF API Session Continuity July 2012 server based on MIF API notification about new interface and new address. It is most case that even the smart terminal get WLAN interface and IP addressed assgined, but it still can not be connected to the Internet, because it hasn't been authenticated by the WLAN web portal. so the trial of the reconnection is needed before physically switch from first interface to the second interface. The recommended steps for the application developer to keep the session continuity based on MIF API are listed below: Step 1: Client connect to the server based on interface 1 (either 3G/ LTE or WLAN); Step 2: Client listen to MIF API for interface and address; Step 3: the 2nd interface is up and get a second IP address, OS will notify the application based on MIF API Step 4: Client try to re-connect to the server from the 2nd interface, if it is connected, prompt to the user, once the user conformed, it will switch the interface. Step 5: User may switch off 1st interface. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations Sometime when the Wifi interface is up, even it has got an IP address, default gateway, and DNS server address, but it may not be connected the Internet because web portal hasn't been successfully authenticated. In this case, even applciation would like to use source address from wifi to re-connect with the server, it may still fail. Some applications may rely on the source address as the credentials, it may need to reestablish the new credential after the application switchs into a new source address. Deng, et al. Expires January 16, 2013 [Page 4] Internet-Draft MIF API Session Continuity July 2012 6. Acknowledgements The author thanks the discussion from Pete McCann, Julien Laganier, Dapeng Liu, et al. in the development of this document. 7. Normative References [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API consideration", draft-ietf-mif-api-extension-00 (work in progress), March 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Hui Deng China Mobile No.32 Xuanwumen West Street Xicheng District, Beijing 100053 China Email: denghui02@gmail.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebecy Canada Email: suresh.krishnan@ericsson.com Ted Lemon Nominum Redwood City, 94063 USA Email: Ted.Lemon@nominum.com Deng, et al. Expires January 16, 2013 [Page 5] Internet-Draft MIF API Session Continuity July 2012 Margaret Wasserman Painless Security, LLC 356 Abbott Street, North Andover 01845 USA Email: mrw@painless-security.com Deng, et al. Expires January 16, 2013 [Page 6]