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
<draft-ietf-pppext-mppp-01.txt>
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]
