Internet DRAFT - draft-gpaterno-wireless-pppoe
draft-gpaterno-wireless-pppoe
Network Working Group
Internet Draft
Document: draft-gpaterno-wireless-pppoe-13.txt Giuseppe Paterno'
Expires: March 2004 November 2003
Using PPP-over-Ethernet (PPPoE) in Wireless LANs
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."
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.
Conventions used in this document
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].
Abstract
This document explores the use of Point-To-Point Protocol over
Ethernet (PPPoE) to provide wireless access to the Internet and
suggests how the infrastructure can be deployed. The document targets
consumers, corporations, Internet Service Providers, and mobile phone
operators that provide user access through Wireless LANs technologies
such as IEEE 802.11.
G. Paterno' Informational [Page 1]
Internet-Draft Using PPPoE in Wireless LANs October 2003
Table of Contents
Status of this memo............................................1
Conventions used in this document..............................1
Abstract.......................................................1
Table of contents..............................................2
1. Introduction................................................3
2. Wireless Standard IEEE 802.11 and Security Concerns.........3
3. Proposed Solution: PPPoE....................................5
3.1. The Authentication Layer..................................5
3.2. The Encryption Layer......................................7
3.3. An Architecture Example...................................8
Abbreviations.................................................10
Normative references..........................................11
Informative references........................................13
Copyright and disclaimer......................................14
Acknowledgments...............................................14
Author's Addresses............................................14
G. Paterno' Informational [Page 2]
Internet-Draft Using PPPoE in Wireless LANs October 2003
1. Introduction
Increased personal mobility and need for network coverage in open
spaces or in places where cabling is difficult (such as airports,
hospitals, warehouses or old buildings) has accelerated the
development of several wireless solutions. Different technologies
exist for transmitting data "over-the-air", for example GSM Packet
Radio Service (GPRS), Bluetooth, and IEEE 801.11, also known as
Wireless Ethernet or Wireless Fidelity (Wi-Fi).
Studies such as [26], [25] and [24] demonstrated that the security
architecture within Wi-Fi, named Wired Equivalent Privacy (WEP), is
feeble and can be broken by motivated malicious users. Moreover, WEP
is not able to uniquely identify the user that is accessing the
network, since it applies cryptography on a per-segment rather than
per-user basis. Before IEEE 802.1x [2] protocol was announced and
implemented, several workarounds has been adopted to overcome the
issue, such as using VPN technologies (IPSec, PPTP, etc.).
This document proposes the adoption of the Point-To-Point Protocol
over Ethernet (PPPoE) [1] as an authentication methodology in
wireless LAN. PPPoE expecially targets Small Office Home Office
(SOHO) users and ISP.
2. Wireless Standard IEEE 802.11b and Security Concerns
Currently the most successful technology in wireless LANs is IEEE
802.11 [8], due to its easy configuration, flexibility, and
cost/performance ratio. In particular, the extension named IEEE
802.11b [9] (also known as 802.11 High Rate or Wi-Fi), one of the
1999 ratifications of the original 802.11 standard, provides wireless
functionality comparable to Ethernet.
IEEE 802.11 focuses mainly on Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) specifications, but it defines also an
optional security feature in the form of encryption, named the Wired
Equivalent Privacy (WEP). WEP was initially developed to give end
users a protection comparable with that available on wired networks.
Recent studies, such as [24] and [25], demonstrated, however, that a
malicious user might gain access to the network by breaking the WEP
keys and without ever needing to supply additional credentials after
that. WEP is based on the RC4 [11] encryption algorithm, a function
that generates a pseudo-random infinitive streaming cypher by
suppling two arguments: the actual WEP key (referred to as K), that
may be 40 or 104 bits long, and the Initial Vector (referred to as
IV), that is 24 bits long. Each IEEE 802.11 frame payload contains
the IV and cyphertext data: cyphertext data is obtained by applying
XOR between the RC4 (IV, K) resulting stream and the clear text.
G. Paterno' Informational [Page 3]
Internet-Draft Using PPPoE in Wireless LANs October 2003
Moreover, when a frame is transmitted a new IV is generated. As the
IV has 16777216 possible values (2^24), the number of IVs would be
exhausted (i.e. it would collide) every 5 hours by constantly
transmitting at 11 Mb/s. With about 1500 IV collisions, and with a
probabilistic attack to the RC4 algorithm, it is possible to decrypt
the transmission and derive the original WEP key. Document [26]
describes in detail the weaknesses of the RC4 algorithm, while
document [25] explains how such weaknesses can be used to break WEP.
The Wired Equivalent Privacy, as it is deployed nowadays, gives
therefore a security feeling to end-users which may be misleading.
Actually, sensitive data, not encrypted anew in the presentation
layer (e.g. through SSL), might be eavesdropped by motivated
malicious users.
Using layer 3 network addresses over the wireless LANs raises also
some concerns. For example, the use of DHCP might be a disadvantage
for those service providers unable to uniquely identify a specific
user, typically for authorisation and accounting purposes. It must
be also considered that, once a malicious user is able to obtain the
WEP key, DHCP immediately gives an IP address and network information
to the intruder (e.g. DNS, WINS, routing, etc.).
Many manufacturers of Access Points (AP) introduced an additional
security feature known as MAC filtering. APs were enabled to
identify MAC addresses of the network cards allowed to access the AP
itself. The use of MAC addresses presents some issues. First one of
manageability: if a user changes his/her wireless adapter, for
example to replace a broken one, he/she must contact the ISP and
communicate his/her new MAC address. Secondly, network cards MAC
addresses can be easily changed by malicious users to find out the
ones with access permissions and so gain access to the Wireless LAN.
G. Paterno' Informational [Page 4]
Internet-Draft Using PPPoE in Wireless LANs October 2003
3. Proposed Solution: PPPoE
3.1. The Authentication Layer
In October 2001, IEEE released the 802.1x protocol that was initially
developed to authenticate wired LAN, and then adopted and modified
for use with Wireless LANs in order to address the security issues
stated in the previous paragraph. The IEEE 802.1x standard [2],
which is based on Extensive Authentication Protocol Over Lan (EAPOL),
is therefore able to authenticate users uniquely and deliver
personalised services such as grouping of users in specific Virtual
LANs. When used over an IEEE 802.11 media, EAPOL is capable of
creating and distributing per-session WEP keys through the EAPOL-Key
frame. More and more AP manufacturers are embracing the IEEE 802.1X
standard, sometimes with proprietary extensions.
Before IEEE 802.1x was available commercially, users tried to find a
solution to the wireless security issues by adopting workarounds such
as adopting VPN techlogogies (IPSec, PPTP, ecc...). With the
depolyement of IEEE 802.1x, workarounds might not be needed anymore
for most of the users, because it combines authentication with a per-
user encryption. Although IEEE 802.1x is the ideal choice for
authenticating Wireless LANs users, it still requires an
infrastructure (i.e. a RADIUS server) which is hard to maintain for
SOHO users and small business that doesn't have dedicated IT
resources. ISPs and mobile operators, instead, might not take
advantage of 802.1x if they resells Virtual Private Dial-up Networks
(VPDN) to smallest ISPs and other big customers: most of the VPDNs
are based on the PPP protocol.
This document proposes the adoption of PPPoE to authenticate wireless
users. ISPs already adopted PPPoE in order to resolve the
authentication layer problem in the broadband world, i.e. ADSL and
cable modems. ADSL and cable technologies are able to emulate an
ethernet network in their standard configuration. Although DHCP is
easy to deploy for a Service Provider, and to configure from an user
perspective, it does not provide a way to authenticate the user, and
therefore cannot be used for accounting or authorization. This need
was solved with the introduction of the Point-To-Point over Ethernet
protocol (PPPoE), described in [1]. Like the previous broadband
technologies, 802.11 is able to emulate an ethernet network. The idea
then is to apply PPPoE technology to Wireless LANs, as it is in ADSL
and cable modems.
The schema below summaries the proposed authentication layer and the
resulting framework:
G. Paterno' Informational [Page 5]
Internet-Draft Using PPPoE in Wireless LANs October 2003
+-------+ +-------+ +----------------+
| HTTPS | | IMAPS | | Other secure | Application-Layer
| | | | | protocol (TLS) | Security
+-------+ +-------+ +----------------+
+-------+ +------------+ +-----------+
| IPSec | | Other | | MPPE/ECP |
| | | encryption | | (3DESE) | Encryption
+-------+ +------------+ | PPP | (optional)
| extension |
+------------------------+ |
| Point-To-Point Protocol | Authentication
| over Ethernet |
+------------------------------------+
+--------+ +----------+ +------------+
| 802.11 | | HyperLAN | | Other WLAN | Physical/Data Link
+--------+ +----------+ +------------+ Protocols
PPPoE can be an easier solution to authenticate users in a SOHO and
small business environment, and for use with legacy APs that do not
support IEEE 802.1x. Furthermore, ISPs might benefit of the adoption
of PPPoE because per-user services can be applied (e.g. fixed IP
address, reserved bandwidth, etc...) and because it makes simpler
selling wholesale services and Virtual Private Dial-up Networks
(VPDNs). By reusing proven technologies, e.g. Layer 2 Tunneling
Protocol (L2TP) [19] or IPSec tunnels, Wireless LAN can extend their
existing dial-up offerings.
Two aspects must be considered while deploying PPPoE, i.e. password
exchange and the Maximum Transmission Unit (MTU) size. As specified
in [1], the Maximum Receive Unit (MRU) option must not be negotiated
to a size larger than 1492; Ethernet has a maximum payload size of
1500 octets. The PPPoE header is 6 octets and the PPP protocol ID is
2 octets, so that the PPP MTU must not be greater than 1492.
However, based on the author's experience, some misbehaved VPN
software packages add their own overhead to the MTU reported by the
PPPoE interface, making the network packets too large to pass through
a PPP over Ethernet connection: reducing the MTU by 32 bytes, i.e.
reducing it to 1460, should generally suffice.
Secondly, it is suggested that passwords might not be exchanged
through the Password Authentication Protocol (PAP) between the user
and the PPPoE concentrator, because PAP transmits passwords in
cleartext: a stronger protocol, such as MS-CHAPv2 [4], should be used
instead.
G. Paterno' Informational [Page 6]
Internet-Draft Using PPPoE in Wireless LANs October 2003
3.2. The Encryption Layer
Although network access can be secured through the adoption of PPPoE,
data is still being sent in clear "over the air", with several
concerns on users' privacy. Data can be easily decrypted even when
WEP is enabled on the Wireless LAN (please refer section 2). Those
who intend to adopt PPPoE as their authentication methodology can
easily encrypt users' data by enabling ECP or MPPE on the PPPoE link.
The Encryption Control Protocol (ECP) [12] is able to configure and
to enable data encryption on both ends of the point-to-point link.
ECP uses the same packet exchange mechanism as the Link Control
Protocol (LCP) and, more generally, provides a framework for
negotiating and applying parameters associated with encryption, e.g.
choosing the algorithm. At present, two algorithms has been defined,
i.e. DESE-bis [13] and 3DESE [14]. Although ECP would be a better
choice than MPPE to encrypt data, the author is not aware of any
implementation of ECP, nor any associated option, and therefore ECP
cannot be immediatly used to secure a Wireless LAN.
The second option is to negotiate the Microsoft Point-To-Point
Encryption Protocol (MPPE) [6] on the point-to-point link. MPPE is a
a PPP Compression Control Protocol (CCP) [15] option that implements
encryption: Microsoft, in fact, created MPPE to secure its Point-to-
Point Tunneling Protocol (PPTP) [23,21]. MPPE is an optional PPP
extension that is negotiated within option 18 [10] in the Compression
Control Protocol, and uses the Rivest-Shamir-Adleman (RSA) RC4 [11]
algorithm to provide data confidentiality. It was originally designed
for encryption across a point-to-point link where packets arrive in
the same order in which they were sent with little packet loss. MPPE
can use 40-bit, 56-bit, or 128-bit encryption keys: the 40-bit key
provides backward compatibility with old clients. The RFC [6]
specifies also a stateless mode for MPPE, which changes the
encryption keys on every packet: most implementations are capable of
negotiating such an option and it is envisaged to use the stateless
mode, when available, to overcome the RC4 algorithm issue on a long-
lived PPPoE session. The MPPE protocol itself is already available
and it has been implemented in several devices and dial-in products.
Therefore MPPE can be a simple, but efficient solution for companies,
ISPs, and Mobile operators who wish to protect users' data.
Whenever corporations need more data confidentiality, the author
suggests to use an application-layer encryption, for example an
SSL/TLS secured applications (HTTPS, IMAPS, etc...), on top of MPPE
or ECP.
G. Paterno' Informational [Page 7]
Internet-Draft Using PPPoE in Wireless LANs October 2003
4. An Architecture Example
In the previous chapter, the Wireless LAN has been compared to a
dial-up infrastructure from a security perspective. Using this
similarity, a typical corporate scenario can be analysed as an
example.
+----------+
| Internet |
+----------+
|
+-------------+ (DMZ1) +-------------------------+
| FE Firewall |--------| External Proxy/DNS/Mail |
+-------------+ +-------------------------+
| (DMZ2)
| +-----------------------+
+--------------| Network Access Server |
| +-----------------------+
|
| +---------------------------+
+--------------| PPPoE Access Concentrator |
| +------------+--------------+
| |
| +------------+-------------+
| | Wireless Access Point(s) |
| +--------------------------+
|
+-------------+ (DMZ3) +------------------+
| BE Firewall |---+----| VPN concentrator |
+-------------+ | +------------------+
| |
| | +------------------+ +---------------+
| +----| Internal Proxy |--| Radius Server |
| +------------------+ +---------------+
+----------+
| Intranet |
+----------+
It has been mentioned that remote access systems, such as modems, are
subject to "war-dialing", i.e. the attempt of a malicious user to
guess the modem telephone number and access the corporate network.
This is the reason why most of IT security policies do not allow
connections using a modem and an analogue phone line to internally
connected computers.
Although, in a corporate security policy, dial-up users are usually
G. Paterno' Informational [Page 8]
Internet-Draft Using PPPoE in Wireless LANs October 2003
considered more "trusted" than global Internet users, they are
however subject to an IP-based inspection (e.g. using firewalls or
access lists) to limit access to corporate resources.
In the example above, dial-up users are placed between two firewalls,
in a zone named DMZ2. The front-end (FE) border firewall separates
global Internet access from externally visible services (DMZ1), which
contains for example DNS and Mail, and remote access users (DMZ2).
DMZ2 is considered more secure than DMZ1: this zone is suitable for
dial-up and Wireless LAN user: both access require the user to supply
credentials to gain access to IP-based network. In particular,
wireless users are subject to PPPoE access verification and
encryption (MPPE) through the PPPoE Access Concentrator (i.e. the
PPPoE server)
Once a dial-up/wireless user has obtained access, a back-end (BE)
firewall connects the DMZ2 to another security zone (DMZ3) and the
corporate Intranet. DMZ3 hosts a RADIUS server to authenticate users,
an internal proxy and a VPN concentrator, which implements encrypted
tunnels for users connecting from the Internet
In a highly-secure environment, the security policies might only
allow an encrypted data flow, e.g. through SSL, from wireless users
in DMZ2 to the Intranet (HTTPS, IMAPS, etc...). For specific
unencrypted applications, e.g. TN3270E mainframe access, the policies
might require a VPN secure tunnel to be established prior to
accessing the service.
G. Paterno' Informational [Page 9]
Internet-Draft Using PPPoE in Wireless LANs October 2003
Abbreviations
ADSL ............. Asymmetric Digital Subscriber Line
AP ............... Access Point
CLID ............. Caller ID
DMZ .............. Demilitarised Zone
EAPOL ............ Extensive Authentication Protocol over Ethernet
ECP .............. Encryption Control Protocol
GPRS ............. GSM Packet Radio Service
GSM .............. Global System for Mobile Communications
IEEE ............. Institute of Electrical and Electronics Engineers
ISP .............. Internet Service Provider
L2TP ............. Layer 2 Tunneling Protocol
LAC .............. L2TP Access Concentrator
LNS .............. L2TP Network Server
MN ............... Mobile Node
MPPE ............. Microsoft Point-to-Point Encryption Protocol
MRU .............. Maximum Receive Unit
MTU .............. Maximum Transmission Unit
NAP .............. Network Access Provider
NAS .............. Network Access Server
NSP .............. Network Service Provider
PAC .............. PPPoE Access Concentrator
PARA ............. PPPoE Advanced Relay Agent
POTS ............. Plain Old Telephone Service
PPPoE ............ Point-To-Point Protocol over Ethernet
PPTP ............. Point-To-Point Tunneling Protocol
SSID ............. Service Set Identifier
SSL .............. Secure Sockets Layer
TLS .............. Transport Layer Security
UMTS ............. Universal Mobile Telecommunications System
VMAC ............. Virtual MAC
VLAN ............. Virtual LAN
WEP .............. Wired Equivalent Privacy
WASS ............. Wireless Access SubSystem
Wi-Fi ............ Wireless Fidelity
WiRAN ............ Wireless Roaming Area Network
WLAN ............. Wireless LAN
G. Paterno' Informational [Page 10]
Internet-Draft Using PPPoE in Wireless LANs October 2003
Normative references
[1] Mamakos, et. al.,
"A Method for Transmitting PPP Over Ethernet (PPPoE)",
RFC 2516, February 1999
[2] Institute of Electrical and Electronics Engineers,
"Local and metropolitan area networks Port-Based Network Access Control",
ANSI/IEEE Standard 802.1X, October 2001
[3] Simpson,
"PPP Challenge Handshake Authentication Protocol (CHAP)",
RFC 1994, August 1996
[4] Zorn,
"Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, January 2000
[5] Aboba & Simon,
"PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999
[6] Pall & Zorn,
"Microsoft Point-To-Point Encryption (MPPE) Protocol"
RFC 3078, March 2001
[7] Kent & Atkinson,
"Security Architecture for the Internet Protocol",
RFC 2401, November 1998
[8] Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications",
ANSI/IEEE Standard 802.11, 1999 Edition
[9] Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications:
Higher-Speed Physical Layer Extension in the 2.4 GHz Band",
IEEE Standard 802.11b, September 1999
[10] Pall,
"Microsoft Point-to-Point Compression (MPPC) Protocol",
RFC 2118, March 1997
G. Paterno' Informational [Page 11]
Internet-Draft Using PPPoE in Wireless LANs October 2003
[11] RC4 is a proprietary encryption algorithm available under
license from RSA Data Security Inc. For licensing information,
contact:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
[12] G. Meyer,
"The PPP Encryption Control Protocol (ECP)",
RFC 1968, June 1996
[13] K. Sklower, G. Meyer,
"The PPP DES Encryption Protocol, Version 2 (DESE-bis)",
RFC 2419, September 1998
[14] H. Kummert,
"The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998
[15] D. Rand,
"The PPP Compression Control Protocol (CCP)",
RFC 1962, June 1996
[16] C. Perkins,
"IP Mobility Support for IPv4",
RFC 3344, August 2002
[17] J. Solomon, S. Glass,
"Mobile-IPv4 Configuration Option for PPP IPCP",
RFC 2290, February 1998
[18] W. Simpson,
"The Point-to-Point Protocol (PPP)"
RFC 1661 / STD 51, July 1994
[19] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter,
"Layer Two Tunneling Protocol (L2TP)",
RFC 2661, August 1999
[20] D. Farinacci, T. Li, S.Hanks, D. Meyer, P. Traina,
"Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000
[21] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn
"Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999
G. Paterno' Informational [Page 12]
Internet-Draft Using PPPoE in Wireless LANs October 2003
[22] J. Reynolds, J. Postel,
"Assigned Numbers",
STD 2, RFC 1700, October 1994.
See also: http://www.iana.org/numbers.html
Informative references
[23] Microsoft Corporation,
"Understanding Point-to-Point Tunneling Protocol (PPTP)",
WhitePaper, September 1999
[24] M. Sutton, iDEFENSE Labs,
"Hacking the Invisible Network. Insecurities in 802.11x",
WhitePaper, July 2002
[25] Stubblefield, Ioannidis, and Rubin,
"Using the Fluhrer, Mantin, and Shamir Attack to Break WEP",
AT&T Labs Technical Report TD-4ZCPZZ, August 2001
[26] Fluhrer, Mantin, and Shamir,
"Weaknesses in the Key Scheduling Algorithm of RC4",
WhitePaper
[27] Cisco Systems,
"Troubleshooting MTU Size in PPPoE Dialin Connectivity",
WhitePaper
[28] Cisco Systems,
"PPPoE Baseline Architecture for the Cisco 6400 UAC",
WhitePaper
[29] Uyless Black,
"Internet Security Protocols: Protecting IP Traffic",
Published by Prentice Hall / Pearson Education in year 2000
G. Paterno' Informational [Page 13]
Internet-Draft Using PPPoE in Wireless LANs October 2003
Copyright and disclaimer
Copyright (C) Giuseppe Paterno' (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the author of this document or
other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the author or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and Giuseppe Paterno' DISCLAIMS ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgments
The author wishes to thank his good friend Luca Sciortino for his
precious moral support and his contribution to this document. Many
thanks go to Maria Di Biccari, Alberto Paterno' and Elisa Stella for
their patience and loveliness.
Author's addresses
Giuseppe Paterno'
Casella Postale 133
20090 Trezzano S/N (MI)
Italy
Email: gpaterno@gpaterno.com
G. Paterno' Informational [Page 14]
