PPP Working Group M. Chuah Internet Draft G. Rai Expires December 1999 J. Teplitsky Lucent Technologies Bell Laboratories D. Grosser IBM Corporation June 1999 Mobile PPP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. Abstract This document describes a new feature for L2TP: it allows for a change of LACs during the lifetime of a PPP session without the latency of re-creating a new PPP session where possible. This feature is especially useful for wireless data services where the foreign wireless service provider (WSP) may be different than the user's home service provider and where a user's mobility may result in a change of LAC during an on-going PPP session. This proposal presents 2 different methods of supporting this feature. The simplest method requires only minor changes to both LACs and LNSs and yields a larger handover latency. The other method has shorter handover latency and Chuah, et al. expires December 1999 [Page 1] INTERNET DRAFT Mobile PPP June 1999 allows the L2TP session to be extended by an additional hop. This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Chuah, et al. expires December 1999 [Page 2] INTERNET DRAFT Mobile PPP June 1999 Applicability These extensions are intended for those implementations which desire to use the mobile feature of L2TP. Table of Contents 1. Introduction ............................................... 4 1.1. Limitations of L2TP for wireless services ................ 5 2. Overview of Mobile PPP ..................................... 5 2.1. Simple AVP Approach (SAA) ................................ 5 2.2. Independent Tunnel Approach (ITA) ........................ 7 3. Service Model Issues ....................................... 10 3.1. Authentication ........................................... 10 3.2. Accounting ............................................... 10 4. Control Message Processing ................................. 11 4.1. Newly Defined Control Message and AVPs ................... 11 4.1.1. Authentication Request (Auth_REQ) ...................... 11 4.1.2. Newly Defined AVPs ..................................... 11 4.1.2.1. Mobile AVP ........................................... 12 4.1.2.2. User's AVP ........................................... 12 5. Security Issues ............................................ 13 6. Legal Issues ............................................... 13 7. Acknowledgements ........................................... 14 8. Contacts ................................................... 14 9. References ................................................. 15 Chuah, et al. expires December 1999 [Page 3] INTERNET DRAFT Mobile PPP June 1999 1. Introduction Serving PPP IWF Server -- -- --------- MN <---> | | <------->| | <----> R ( Internet) -- -- --------- MN: Mobile Node R: Router IWF: Interworking Function Figure 1: Typical wide area wireless access network architecture Figure 1 shows the architecture of a typical wide area wireless access network like CDMA, GSM, or TDMA. Current wireless standards allow mobile nodes (MN) to dial up a PPP server to access the inter- net. A link level tunnel is created between the serving IWF and the PPP server. If the mobile node moves to another serving IWF, link- layer messages are exchanged so that the tunnel between the old serv- ing IWF and the PPP server is torn down and a new one set up between a new serving IWF and the PPP server. If the mobile node moves further such that it has to change the PPP server, then current wire- less standards force a termination of the PPP session. A new PPP ses- sion has to be negotiated between the mobile node and the new PPP server. In addition, current wireless standards do not provide vir- tual private networking services to mobile nodes. In current wireless architectures, the PPP server authenticates mobile nodes using the negotiated PPP authentication protocol e.g. CHAP. Since it is not aware of mobile node handovers in the wireless network, it does not perform any authentication when a mobile node changes its serving IWF. In this document, we propose a mobile feature to the current IETF L2TP protocol to provide wide area mobility to nodes without having to renegotiate the PPP session during a handover. According to this proposal, mobile nodes need only implement the TCP/IP/PPP stack with no modifications. All current PCs and the future crop of hand held data devices are expected to have this stack. There are two methods to provide this mobile feature, namely (a) Sim- ple AVP Approach (SAA), (b) Independent Tunnel Approach (ITA). Both the SAA and ITA require changes to both LAC and LNS software. We list the advantages and disadvantages of these 2 different approaches in later sections. Chuah, et al. expires December 1999 [Page 4] INTERNET DRAFT Mobile PPP June 1999 This proposal is independent of the wireless access technologies. It provides a way to carry mobile node security credentials between net- work access servers in a technology independent manner. It also makes no assumptions about the methods by which wireless terminals are identified or about the encryption and authentication methods used by the wireless networks. 1.1. Limitations of L2TP for wireless services The current L2TP draft [1] does not allow for a transfer of Network Access Server (NAS) during an existing PPP session. In a cellular environment, a change of NAS may occur during the lifetime of a PPP session. A user may start a PPP session and move into another service provider's coverage area which has a different NAS. The current L2TP draft forces the user to drop the currrent PPP session and renego- tiate a new session. Instead of terminating the existing PPP session and starting a new one which takes time and can be expensive in high capacity, micro-cellular wireless networks, one solution is to let the old NAS (LAC) transfer the PPP session to the new NAS (LAC). The current L2TP draft also does not allow mobile data users visiting a foreign wireless ISP to use the wireless ISP for virtual private networking services from an area where their home (wireless) ISP is not in operation. 2. Overview of Mobile PPP The mobile feature can be provided using two methods which differ in terms of their implementation complexity. These two methods are (i) Simple AVP Approach (SAA), (ii) Independent Tunnel Approach (ITA). 2.1. Simple AVP Approach (SAA) In the Simple AVP approach, both the existing LAC and LNS need to be enhanced to process the User AVP, a newly defined AVP. -------- ---------- | Old | Tunnel=2 | | | LAC | ----------| LNS | -------- callid=5 --------- / / Chuah, et al. expires December 1999 [Page 5] INTERNET DRAFT Mobile PPP June 1999 / Tunnel=3, callid=1 --------- | New LAC | --------- New LAC LNS Old LAC Link Msg 1 SCCRQ ---> ----------------------> SCCRP (with Mobile AVP) <-------------------- SCCCN -------------------> ICRQ (with User AVP) ---------------------> CDN ----------> ICRP (with ACCM AVP) <-------------------- ICCN -------------------> User-level reauthentication (optional) <--------------------------------> Figure 2: Simple AVP Approach In Figure 2, we assume that the link layer message contains some sub- scriber information. Such information allows the new LAC, via the help of its local AAA server, to determine which LNS the new LAC should connect with. During tunnel setup, the LNS MUST include the new Mobile AVP in its SCCRP if it supports the mobility feature. The new LAC MUST NOT attempt to use the mobility feature unless the Mobile AVP is received during tunnel setup. It is assumed that if LNS supports the mobile feature and requires user level reauthentication, then the LNS will use CHAP or other related authentication mechanism that supports reauthentication. An LNS that supports the mobility feature MUST interpret a ICRQ with an attached User AVP as a handover request for an existing PPP call. Using the information provided in the User AVP, the LNS can use its connection table to determine the which call is to be exchanged. Chuah, et al. expires December 1999 [Page 6] INTERNET DRAFT Mobile PPP June 1999 If the LNS cannot accept the call handover, the LNS MUST send a CDN message to the new LAC. If the LNS can accept the handover, the LNS MUST send a Call Disconnect Notify (CDN) message to the old LAC and reply with an ICRP message to the new LAC as stated in [1]. To sup- port the handover feature, the ACCM AVP need to be included in the ICRP message. L2TP sequence numbers will be re-initialized after the handover. The advantage of SAA is : (a) it is very simple. The disadvantages of SAA are: (a) Both the LAC and LNS software need to be updated to recognise the newly defined User AVP message. (b) The handover latency may be long since the LAC may be located within the WSP intranet while the LNS is located within the ISP or corporate network far away. (c) Roaming service may be limited to a smaller geographical area because the LACs within the WSP intranets and the LNSs within a corporate network do not trust one another unless there is a direct agreement between different WSPs and the corporate net- work. However, there may be cases where this approach is not secure or feasible. For such cases, we may need to extend the PPP session to a 2-hop session. A new entity called the Anchor LAC is introduced for the 2-hop session. 2.2. Independent Tunnel Approach (ITA) In the Independent Tunnel Approach, there are two L2TP data sessions per PPP call: one between the Serving LAC and the Anchor LAC; one between the Anchor LAC and LNS. To the Serving LAC, the Anchor LAC looks like the LNS. To the LNS, the Anchor LAC looks like the LAC. The Anchor LAC needs to provide a mapping table to map the tunnel and call identities of one data session to those of the related data ses- sion that belong to the same PPP call. Thus, the Anchor LAC has to maintain 2N data sessions for N PPP calls in ITA. ---------- -------- | Anchor | Tunnel=1 | LNS | | LAC |-----------| | --------- callid=3 -------- | | | Tunnel=3, callid=1 ------------- Chuah, et al. expires December 1999 [Page 7] INTERNET DRAFT Mobile PPP June 1999 |Serving LAC | ------------- S-LAC: Serving LAC A-LAC: Anchor LAC Client S-LAC A-LAC LNS Link Layer Msg1 SCCRQ ---------> ----------> SCCRP (with Mobile AVP) <--------- SCCCN ------------> ICRQ (with User AVP) -------------> ICRP (with ACCM AVP) <------------- ICCN -------------> ACK <---------- User-level Reauthentication <---------------------------------------> Link Layer Msg2 <--------- One hop to 2-hop Handover Scenario Figure 3: Independent Tunnel Approach In Figure 3, we assume that the mobile subscriber first establishes a PPP call between the Anchor LAC and the LNS (tunnelid=1, callid=3). Then, the mobile subscriber roams to the coverage area of another new LAC (referred to as the Serving LAC). From the link-layer handoff message, the Serving LAC discovers that there is an existing PPP call. Thus, the Serving LAC sends an ICRQ message which contains a User AVP. The Anchor LAC will first determine if this existing PPP call requests for an extended hop or for a change of LAC. Such a decision can be made with the help of the local AAA server and the information contained in the User AVP. Next, the Anchor LAC decides if this PPP call already has a 2-hop L2TP tunnel. If the Anchor LAC determines that this existing PPP call needs an extended hop, it will create an entry in its mapping table (MT) so that the L2TP headers of all packets with (tunnelid=1,callid=3) from the incoming interface can be swapped with an L2TP header with (tunnelid=3, callid=1) at the Chuah, et al. expires December 1999 [Page 8] INTERNET DRAFT Mobile PPP June 1999 outgoing interface. If a user-level re-authentication is desired, the Anchor LAC can send an Authentication Request message (an optional newly defined L2TP control message) to the LNS. LNS can then re- authenticate the user. Again, as before, we assume that LNS uses CHAP or any other authentication mechanism that supports reauthentication. If re-authentication fails, the connection will be torn. -------- ---------- -------- |Serving| Tunnel=3 | Anchor | Tunnel=1 | LNS | | LAC1 | ----------| LAC |-----------| | -------- callid=1 --------- callid=3 -------- / / / Tunnel=2, callid=5 ------------- | New | |Serving LAC2 | ------------- Client S-LAC2 A-LAC LAC1 LNS Link Layer Msg1 SCCRQ ---------> ----------> SCCRP (Mobile AVP) <--------- SCCCN ------------> ICRQ (with User AVP) -------------> CDN ------------> ICRP <------------- ICCN Auth_Req (Optional) -------------> ------------------------> ACK <---------- Link Layer Msg2 <--------- 2-hop to 2-hop Handover Scenario Figure 4: Independent Tunnel Approach Chuah, et al. expires December 1999 [Page 9] INTERNET DRAFT Mobile PPP June 1999 In Fig 4, we show a 2-hop to 2-hop handover scenario. When the Anchor LAC receives the ICRQ with an attached User AVP, and finds an entry in the mapping table, it concludes that this is a 2-hop to 2-hop handover scenario. Therefore, the Anchor LAC sends a CDN message to the old LAC, and updates the mapping table with the new tunnel and call identities carried within the ICRQ message. Again, if a user- level re-authentication is desired, the Anchor LAC can send an Authentication Request message to the LNS to trigger such a reaction. The advantages of ITA are: (a) the handover latency is reduced due to a shorter hop distance between the Serving LAC and the Anchor LAC. The hop between the Anchor LAC and the LNS remains unchanged. (b) Roaming service can be more flexible. As long as there is an agree- ment between the home WSP and the corporate network, and between the home WSP and other WSPs, the subscribers can roam to more places without having to terminate the PPP session. The disadvantages of ITA are (a) more complex than the Simple AVP approach (b) the Anchor LAC needs to maintain 2N flow-controlled data sessions for N PPP calls. 3. Service Model Issues 3.1. Authentication As in [1], the authentication of the user occurs in four phases; the first at the visiting WSP, the second at the Home WSP, and the third and optionally the fourth at the LNS. 3.2. Accounting It is a requirement that the Serving LAC, the Anchor LAC and the LNS be capable of providing accounting data and hence all three parties may count packets, octets and connection start and stop times. Accounting statistics collected by the Serving LAC and the Anchor LAC are sent to their AAA Servers. The accounting Server in the Foreign Network may forward accounting statistics to the Home Accounting Server periodically (weekly, monthly). Chuah, et al. expires December 1999 [Page 10] INTERNET DRAFT Mobile PPP June 1999 4. Control Message Processing For the 3-hop scenario, we assume that any party, namely the Serving LAC, the Anchor LAC or the LNS can terminate the session by sending a Call Disconnect Notify. If the Anchor LAC desires to terminate the session, then the Anchor LAC has to send a Call Disconnect Notify message to both the Serving LAC and the LNS. Note that in the three hop scenario, the Hello messages for the con- trol connections between the Serving/Anchor LACs and between the Anchor LAC and LNS are done independently of one another for the Independent Tunnel approach. The Anchor LAC is expected to relay all the Set-Link-Info, and Wan-Error-Notify messages. 4.1. Newly Defined Control Message and AVPs To support the tunnel extension and call transfer features, we define one optional control message, namely the Auth_Request (Auth_REQ) mes- sage. This message allows the LAC to inform the LNS to trigger a PPP level re-authentication with the PPP client during handover. In addition, we define three new AVPs: (i) Mobile AVP, (ii) User AVP, 4.1.1. Authentication Request (Auth_REQ) Authentication Request message is sent from a LAC to an LNS to trigger the LNS from initiating a PPP reauthentication with an exist- ing user. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type=17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Authentication Request 4.1.2. Newly Defined AVPs The new AVP is encoded as Vendor ID 1751 which reflects Lucent Systems, the initial developer of this specification, and it should be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). Chuah, et al. expires December 1999 [Page 11] INTERNET DRAFT Mobile PPP June 1999 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Overall Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [until Overall Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first six bits are a bit mask, describing the general attributes of the AVP. The three newly defined AVPs are: Attr M Len Attribute Name 40 1 6 Mobile AVP 41 1 16+ User AVP 4.1.2.1. Mobile AVP This AVP is used by the LNS/A-LAC to inform a LAC that the LNS/A-LAC supports the mobility feature. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0|0| Length | Lucent-Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Mobile AVP Format 4.1.2.2. User's AVP This AVP is used to provide user's name and user's credentials. The user's credentials may include information like user's identity (IMSI), phone number. Message Format for User's AVP 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chuah, et al. expires December 1999 [Page 12] INTERNET DRAFT Mobile PPP June 1999 |1|1|0|0| Length | Lucent-Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 41 | User-Service | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCII Representation of 15 digit No | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Phone-No | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old LAC's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Serial No | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User's AVP - contains information about the user's name and user's creden- tials e.g. multihop virtual dial up service, user's identity (MIN), ser- vice provider's phone number, user level authentication information, etc. It also includes a combination of both the IP Address of the old LAC and the call serial number if both exist. This pair of information can uniquely identify an existing PPP session. 5. Security Issues In our proposal, the Serving and Anchor LACs may belong to the same WSP or they may belong to different WSPs. For the case where they belong to the same WSP, we do not introduce any new security threats. For the case where they belong to different WSPs, we assume that both the LAC and LNS will support the Authentication Request AVP. We further assume that LNS uses CHAP such that user-level reauthentica- tion can be done with the PPP client if the LNS so desires. In addition, IP security can be supported between the Serving LAC and LNS for the 2-hop scenario using extended ideas described in the draft "Securing L2TP using IPSEC" [2]. 6. Legal Issues The patent licensing policy of Lucent Technologies Inc with respect Chuah, et al. expires December 1999 [Page 13] INTERNET DRAFT Mobile PPP June 1999 to any patents or patent applications relating to this submission is stated in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker, Intellectual Property Vice President, Lucent Technologies, Inc. This letter is on file in the offices of the IETF Secretariat. 7. Acknowledgements The author wishes to thank George Gross for comments on earlier ver- sion. 8. Contacts M. C. Chuah Lucent Technologies 101, Crawfords Corner Road, Holmdel, NJ 07733 chuah@lucent.com (732)-949-7206 Don Grosser IBM Corporation 3039 Cornwallis Road, Research Triangle Park, NC 27709 grosser@us.ibm.com (919)-254-2160 G. Rai 1101 Warrenville Road, Naperville, IL grai@lucent.com (630)-979-8131 Jacob Teplitsky RABU Lucent Technologies 4464 Willow Rd, Pleasanton, CA 94588 jacobt@livingston.com (925)-737-2189 Chuah, et al. expires December 1999 [Page 14] INTERNET DRAFT Mobile PPP June 1999 9. References [1] A. Valencia, etal, Layer Two Tunneling Protocol, Internet draft, draft-ietf-pppext-l2tp-116.txt, June, 1999 [2] B. Patel, B. Aboba Security L2TP using IPSEC, Internet draft, draft-ietf-pppext-l2tp-security-01.txt, March 1998 Chuah, et al. expires December 1999 [Page 15]