Internet Draft Kevin Purser, editor Document: draft-purser-pppext-pppcn-00.txt Ericsson Expires: March 2004 September 2003 PPP Adaptation for Cellular Networks Status of this Memo This document is an Internet-Draft and is subject to 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract If the Internet is accessed via cellular networks, the Point-to-Point protocol (PPP) is most commonly used for configuration of the circuit-switched or packet-switched link. Thus, this PPP configuration time comes in addition to the usual call-setup time for the cellular connection. In many cases this will result in a fairly long "wait time" as perceived by end users before actual application data can be transmitted. This proposal describes a solution in which the PPP configuration time can be significantly reduced (on the order of seconds) in cases where both peer protocol entities can be modified according to this proposal, which involves modifying standard PPP. In cases where one PPP peer is modified and the other utilizes only standard PPP, the modified peer can fallback to standard PPP operation. This fallback mechanism will not noticeably affect the PPP setup time, and serves to ensure interoperability. Purser expires March 2004 [Page 1] Internet Draft PPP-CN September 2003 1. Introduction In cellular networks, direct access to the internet is provided to mobile users via the PDSN in CDMA2000 or the MSC/GSN in GSM/GPRS. The Point-to-Point Protocol (PPP) is first used to configure the traffic channel between the terminal equipment (TE) and the cellular network node and subsequently to transport network layer protocol data units (PDU) over the traffic channel. Since PPP was initially designed to run over the wire, it normally requires numerous exchanges of signaling messages (figure 1) between the two peers to configure their connection, namely LCP, IPCP, etc. +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req | |------------------------------>| | LCP-Req-Ack | |<------------------------------| | PAP/CHAP-Req | |------------------------------>| | PAP/CHAP-Req-Ack | |<------------------------------| | IPCP-Req | |------------------------------>| | IPCP-Req-Ack | |<------------------------------| | | Figure 1: Common message exchanges involved in PPP negotiation For the sake of simplicity, the LCP- and IPCP- Requests initiated concurrently by the 3G node are not shown in figure 1. In addition, CHAP also requires a 3-way handshake as opposed to the 2-way handshake for PAP initiated by the TE as indicated. However, this does not change the overall PPP configuration time, since the 3G node can send the CHAP challenge immediately following the LCP-Req-Ack. Note that standard PPP [PPP] specifies that neither the PAP/CHAP authentication phase, nor the IPCP configuration phase, nor the exchange of IP packets can begin prior to the completion of the preceding phase. This results in a minimum duration of the PPP negotiation of 2 or 3 round trip times (RTT), depending on whether the optional authentication phase is employed. With PPP in use traditionally over wired links, these multiple round trips aren't of major consequence. Cellular links on the other hand are characterized by high latency and a much higher rate of packet loss. Thus, the negotiation shown in figure 1 when applied to Purser expires March 2004 [Page 3] Internet Draft PPP-CN September 2003 cellular networks can typically comprise 7 RTTs or more, due to retransmissions after packet loss, additional PPP negotiation parameters, etc. This number of round trips, considering that the average RTT in GSM today is approximately 750ms, can easily result in PPP negotiation setup times of several seconds. 1.1. Acronyms This section lists acronyms commonly used throughout this document. CHAP - Challenge-Handshake Authentication Protocol GSN - GPRS Support Node IPCP - Internet Control Protocol LCP - Link Control Protocol MRU - Maximum Receive Unit MSC - Mobile Switching Center PAP - Password Authentication Protocol PDSN - Packet Data Serving Node PDU - Protocol Data Unit PPP - Point-to-Point Protocol RTT - Round Trip Time TE - Terminal Equipment 1.2. Definitions This section lists terms commonly used throughout this document. Standard-PPP-Peer: A PPP peer which only implements PPP as specified in [PPP]. PPPCN-Peer: A PPP Peer which implements a modified PPP state machine which allows it to conform to standard PPP as specified in [PPP] when required, but also to conform to the enhanced PPP as defined in this document. Masked PPP packets: LCP, PAP, CHAP, IPCP or IP packets with syntax and semantics as defined in [PPP], but carrying an "incorrect" value in the PPP protocol field. Protocol fields values of these packets MUST NOT be reserved (see [Num]), and MUST be uniquely chosen conforming to [PPP] with respect to how valid protocol fields values are defined. For example, protocol field values chosen from the 0x8001 to 0x801F (hex) range would be acceptable candidates. PPPCN- Peers will accept and process these packets, but as put forth in [PPP], Standard-PPP-Peers MUST silently discard these packets. 2. Protocol Description The general premise of this protocol is that when 2 PPPCN-Peers begin Purser expires March 2004 [Page 4] Internet Draft PPP-CN September 2003 negotiating PPP setup, the strict separation of LCP, authentication (PAP or CHAP) and IPCP phases as well as the exchange of IP packets will no longer be required. Instead, both peers will assume a pre- defined set of LCP and IPCP options as defined in figure 2, and initiate the aforementioned phases concurrently as follows. ====================================================== protocol | option | default value ---------+----------------------------+--------------- LCP | MRU | 576 ---------+----------------------------+--------------- LCP | Authentication Protocol | not required ---------+----------------------------+--------------- LCP | Quality Protocol | not required ---------+----------------------------+--------------- LCP | Magic Number | not required ---------+----------------------------+--------------- LCP | Protocol Field Compression | required ---------+----------------------------+--------------- LCP | Address/Control Field Comp | required ---------+----------------------------+--------------- IPCP | IP-Addresses | not required ---------+----------------------------+--------------- IPCP | IP-Compression Protocol | not required ---------+----------------------------+--------------- IPCP | IP-Address | required ---------+----------------------------+--------------- IPCP | TCP/IP Header Compression | required ====================================================== Figure 2: Default values to be used for LCP and IPCP phases of PPP negotiation A PPPCN-Peer MUST begin negotiations by sending an initial set of masked PPP packets, where each packet is sent immediately following the preceding packet, without waiting for an acknowledgement of any kind. This MUST be immediately followed by a standard LCP packet. The standard LCP packet MUST carry all options of the pre-defined set that differ from the default options specified in [PPP]. A receiving Standard-PPP-Peer MUST silently discard the masked PPP packets as specified in [PPP], and begin by processing the standard LCP packet. On the other hand, a receiving PPPCN-Peer MUST silently discard the standard LCP packet but instead begin by processing the masked PPP packets. Optionally, a PPPCN-Peer may change pre-defined LCP or IPCP settings (e.g. the MRU to a value between 296 and 1500) by sending an appropriate masked LCP or IPCP packet as a part of the aforementioned Purser expires March 2004 [Page 5] Internet Draft PPP-CN September 2003 initial set of masked PPP packets. This MAY or MAY NOT be accepted by the receiving PPPCN-Peer which MUST respond with a masked ACK or NACK, respectively. A receiving PPPCN-Peer will be able to determine by inspecting the first packets whether it is communicating with a Standard- or PPPCN- Peer. Thus, in order to guarantee interoperability, a PPPCN-Peer which only receives a standard LCP packet MUST fallback to operate as a Standard-PPP-Peer. Likewise, a Standard-PPP-Peer which receives any masked PPP packets will silently discard them and acknowledge the starting standard LCP packet, thus indicating to the originating PPP- Peer to fallback into Standard-PPP-Peer mode. PPPCN-Peers MUST support both PAP and CHAP, but the PPPCN-Peer in the 3G cellular node dictates the authentication protocol to be used. If authentication is required, any masked IP packets received during the PPP negotiation by a PPPCN-Peer MUST be buffered and MUST NOT be forwarded to the receiving IP peer until the necessary PPP negotiation phases have succeeded. In the case of any unsuccessful phase of the PPP negotiation between two PPPCN-Peers (e.g. the authentication fails but an IP address has already been assigned, and IP packets received), the link MUST be terminated, and any state in the 3G cellular node (any assigned IP addresses, received IP packets, etc) regarding the originating PPPCN- Peer MUST be discarded, and any allocated IP addressed MUST be de- allocated. 3. Use Cases This section will illustrate a few example scenarios. The following cases assume that a PPPCN-Peer in the TE communicates with a PPPCN- Peer in the 3G Node, and accordingly, all packets shown are masked PPP packets unless otherwise noted. For the sack of brevity, we have omitted optional masked LCP/IPCP packets for changing pre-defined settings. Also, packets sent immediately after one another are drawn with the same arrow, to indicate concurrency. Purser expires March 2004 [Page 6] Internet Draft PPP-CN September 2003 Case 1: TE does not initiate authentication and the 3G node does not require authentication. +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req + | | IPCP-Req + | | Standard LCP-Req | |------------------------------>| | LCP-Req-Ack + | | IPCP (IP address) | |<------------------------------| | First IP packet | |------------------------------>| | | Case 2: TE does not initiate authentication, but the 3G node requires the use of PAP authentication +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req + | | IPCP-Req + | | Standard LCP-Req | |------------------------------>| | LCP-Req-Ack + | | PAP-Required + | | IPCP (IP address) | |<------------------------------| | PAP-UserID/Password + | | First IP packet | |------------------------------>| | | Purser expires March 2004 [Page 7] Internet Draft PPP-CN September 2003 Case 3: TE initiates using PAP authentication, but the 3G node requires the use of CHAP authentication +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req + | | PAP-UserID/Password + | | IPCP-Req + | | Standard LCP-Req | |------------------------------>| | LCP-Req-Ack + | | PAP-Nack + | | CHAP-Challenge + | | IPCP (IP address) | |<------------------------------| | CHAP-UserID/Password + | | First IP packet | |------------------------------>| | | 4. Security Considerations Security considerations are not discussed in this memo. However, since the aim of this protocol is merely to reduce PPP negotiation time by allowing the distinct negotiation phases to happen concur- rently instead of in a serial fashion, there should not be any addi- tional security risks introduced which are not already present in [PPP]. 5. Acknowledgements The author wishes to acknowledge Reiner Ludwig and Martin Gerdes, the original authors of this solution as presented in [QPPP]. 6. Author's Addresses Kevin Purser 8400 Decarie Blvd. Town of Mount Royal, Quebec H4P 2N2 CANADA Phone: +1-514-345-7900 Email: kevin.purser@ericsson.ca 7. References Purser expires March 2004 [Page 8] Internet Draft PPP-CN September 2003 [PPP] W. Simpson (editor), "The Point-to-Point Protocol (PPP)", RFC1661, July 1994 [IPCP] G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992 [PPPAuth] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992 [Num] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1340, July 1992 [QPPP] R. Ludwig, B. Rathonyi, "Link Layer Enhancements for TCP/IP over GSM", In Proceedings of IEEE INFOCOM, March 1999 Purser expires March 2004 [Page 9] Internet Draft PPP-CN September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Purser expires March 2004 [Page 1]