Network Working Group Internet Draft Document: draft-gpaterno-wireless-pppoe-10.txt Giuseppe Paterno' Expires: September 2003 March 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' Experimental [Page 1] Internet-Draft Using PPPoE in Wireless LANs February 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. Current Wireless LAN scenario...............................3 2.1. Wireless standard IEEE 802.11 and security concerns.......3 2.2. Existing authentication methodologies.....................4 3 Proposed solution............................................5 3.1. The authentication layer: PPPoE...........................5 3.2. The encryption layer......................................8 3.3. An architecture example...................................9 4. The Wireless Roaming Area Network (WiRAN)..................11 4.1. Mobile Node (MN).........................................12 4.2. Wireless Access SubSystem (WASS).........................12 4.2.1. Access Point (AP)......................................12 4.2.2. PPPoE Advanced Relay Agent (PARA)......................13 4.3. PPPoE Access Concentrator (PAC)..........................14 4.3.1. Native mode............................................14 4.3.2. Encapsulation Mode.....................................15 5. Conclusions................................................17 Acronyms......................................................18 Normative references..........................................19 Informative references........................................21 Copyright and disclaimer......................................22 Acknowledgments...............................................22 Author's Addresses............................................22 G. Paterno' Experimental [Page 2] Internet-Draft Using PPPoE in Wireless LANs February 2003 1. Introduction Current wireless LAN technologies provide a feeble security architecture that can be broken by motivated malicious users. Moreover, these technologies are not able to uniquely identify the user that is accessing the network: as a result corporations, ISPs, and mobile operators are unable to apply appropriate rights and/or services to end-users. This document proposes the adoption of the Point-To-Point Protocol over Ethernet (PPPoE) [1] as an authentication methodology in wireless LAN and as an additional security component. Furthermore, it explores how consumers, corporations, ISPs, and mobile operators would benefit from the adoption of PPPoE as an alternative solution to IEEE 802.1X. 2. Current Wireless LAN scenario 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). 2.1. Wireless standard IEEE 802.11 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), was one of the 1999 ratifications of the original 802.11 standard and it 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 G. Paterno' Experimental [Page 3] Internet-Draft Using PPPoE in Wireless LANs February 2003 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. Moreover, when a frame is transmitted a new IV is generated: as the IV has 16777216 possible values (2^24), the number of IV would be repeated (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 gives therefore a false security feeling to end-users, as sensitive data, not encrypted in the presentation layer (e.g. through SSL), can be easily 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. We must also consider that, once a malicious user gains access to the WEP keys, 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 additinal 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. 2.2. Existing authentication methodologies The IEEE 802.1X standard [2], based on Extensive Authentication Protocol Over Lan (EAPOL), aimed at addressing the security issues of Wireless LANs. This protocol provides user authentication for both wireless and wireline LANs: it allows unique user identification and therefore makes it possible to provide personalised services such as grouping of users in specific Virtual LANs. While the enhancements proposed by both IEEE 802.1X and the work-in- progress IEEE 802.11i could improve security of 802.11 networks, these solutions came on the market too late, causing impatient vendors to implement proprietary ad-hoc solutions. These vendors may G. Paterno' Experimental [Page 4] Internet-Draft Using PPPoE in Wireless LANs February 2003 not be willing to replace their proprietary fixes with 802.11i when it will become available. Many of the high-end AP manufacturers anyway embraced the IEEE 802.1X standard, sometimes with proprietary extensions. Although 802.1X provides flexibility and extended LAN support, compliant APs are still quite expensive for small businesses and consumers. In fact, to this day, many of the Wireless Access Points and hub/switches do not support EAPOL. Furthermore, many APs which are 802.1X compliant do not implement the dynamic WEP-key exchange feature [2] (EAPOL-Key), thus raising a potential security issues. A great number of consumers, of small ISPs and of small businesses cannot afford such an expensive solution, but nevertheless they need security and need to be able to uniquely identify users who can access their resources. In fact, some malicious users are today gaining access to users' home equipment through Wireless LANs, and attacking remote sites while fully preserving their anonymity. It also has to be considered that many ISPs and mobile operators are not interested in implementing encryption for wireless connections, e.g. connections for public Internet access, but nevertheless they need unique user identification for billing purposes. The ideal solution for ISPs and mobile operators would then be one that easily and with little effort integrates with their existing dial-up infrastructure (e.g. modem, GPRS, etc.), while enabling end users to access customised services such as fixed IP address, Quality of Service, etc. 3. Proposed solution 3.1. The authentication layer: PPPoE With the introduction of cable and ADSL technologies, ISPs have adopted a methodology for resolving the authentication layer problem for the broadband world. 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]. Through the adoption of this protocol, access control, billing, and several type of services can be performed on a per-user, rather than a per-site or cell basis. G. Paterno' Experimental [Page 5] Internet-Draft Using PPPoE in Wireless LANs February 2003 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. The advantage is clear: consumers, corporations, Internet Service Providers, and mobile operators can perform authentication, authorisation, and accounting easily on the wireless users without adding new components and, more importantly, with little effort. The schema below summaries the proposed authentication layer and the resulting framework: +-------+ +-------+ +----------------+ | HTTPS | | IMAPS | | Other secure | Application Layer | | | | | protocol (TLS) | +-------+ +-------+ +----------------+ +-------+ +------------+ +-----------+ | IPSec | | Other | | MPPE/ECP | | | | encryption | | (3DESE) | Encryption Layer +-------+ +------------+ | PPP | (optional) | extension | +------------------------+ | | Point-To-Point Protocol | Authentication Layer | over Ethernet | +------------------------------------+ +--------+ +----------+ +------------+ | 802.11 | | HyperLAN | | Other WLAN | Physical/Data Link Layer +--------+ +----------+ +------------+ There are several advantages of embracing the PPPoE technology, one of them is providing fixed IP addresses and specific Quality Of Service (QoS) to a roaming wireless user: wherever the user is located, he/she can have his/her IP address and his/her personalised services. Another advantage of using PPPoE is that no IP address is physically bound to any network component. Both the wired network and the wireless user are protected from any attack, because any malicious user would have to break the PPP layer to gain access to the IP-based network. From the perspective of a traditional ISP or a corporation, there is no additional benefit in using PPPoE technology, if compared to IEEE 802.1X, because of the PPP frame overhead. However, one aspect must be considered when deploying IEEE 802.1X: current implementations are based on EAP-TLS [5]. Although EAP-TLS is the perfect choice for corporations that already deployed X.509 certificates, it is not G. Paterno' Experimental [Page 6] Internet-Draft Using PPPoE in Wireless LANs February 2003 appropriate for ISPs, mobile operators and corporations that do not own, or plan to have, an X.509 infrastructure. Creating and maintaining a PKI infrastructure is expensive, especially if a public Certification Authority is used, and requires expert human resources dedicated to the PKI. Moreover, non 802.1X compliant Access Points should be replaced. Nevertheless, it has to be considered that Network Access Provider (NAP) or Network Service Provider (NSP) will benefit of the adoption of PPPoE, 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 existing NAP dial-up offerings. For consumers, small businesses, and local ISPs the PPPoE overhead is not an issue, if compared to the cost of deploying both hardware and EAPOL compliant software to the client. The advantage of using PPPoE is that the user is uniquely identified, by preserving the existing access points and with a simple additional component (the PPPoE server). As a result, corporate and ISPs are able to protect their resources by adding a PPPoE server. This approach is easier to deploy if compared to EAPOL with EAP-TLS, that requires a more complex infrastructure and management. It has to be considered that most of today's operating systems include a PPPoE client, resulting in a low cost deployment for this technology because no additional software is required. Finally, Access Point manufacturers can easily embed a PPPoE server in their products and provide an easy configuration, e.g. through a web interface. To provide the new service to APs already deployed, the PPPoE server might be distributed as a firmware update. However, two aspects has to 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. Passwords instead must 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], EAP-TLS [5] or better should be used instead. G. Paterno' Experimental [Page 7] Internet-Draft Using PPPoE in Wireless LANs February 2003 3.2. The encryption layer A Wireless LAN, being "over-the-air", might be considered a public switched network, analogous to the telephone network. For example, in the traditional Plain Old Telephone Service (POTS), a malicious user can intercept PPP packets by tapping the phone wire. The Wireless LAN can be managed therefore as a dial-up connection, so that encryption and/or access policies should be applied, e.g. protecting the access through a firewall or a proxy, allowing only specific applications. As a result, it is recommended that Wireless users should add an encryption layer on top of their connection. The ideal choice for encrypting wireless traffic would take advantage of a PPP extension, named Encryption Control Protocol (ECP) [12], which configures and enables 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], but the author is not aware of any implementation of ECP nor any associated option, making it difficult to immediately deploy the solution. However, a PPP Compression Control Protocol (CCP) [15] option, named Microsoft Point-To-Point Encryption Protocol [6], implements encryption, other than compression: Microsoft, in fact, created MPPE to apply security to 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 deployed in several devices and dial-in products. MPPE therefore could be a simple, but efficient solution for companies, ISPs and mobile operators who wish to implement secure wireless access. As ECP is not yet available, some specific customers (e.g. finance and government) might require higher-grade encryption than the one provided by MPPE. An easy solution is the adoption of an application G. Paterno' Experimental [Page 8] Internet-Draft Using PPPoE in Wireless LANs February 2003 layer encryption technique, e.g. through SSL, to be added on top of the MPPE PPP-layer encryption. Other suggested solutions are the adoption of IPSec [7], the Point-to-Point Tunneling Protocol (PPTP) [23,21], or other encryption technologies. 3.3. 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. G. Paterno' Experimental [Page 9] Internet-Draft Using PPPoE in Wireless LANs February 2003 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 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 a 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 access the service. G. Paterno' Experimental [Page 10] Internet-Draft Using PPPoE in Wireless LANs February 2003 4. The Wireless Roaming Area Network (WiRAN) The meaning of the word "roaming" is sometimes misinterpreted: most Wireless LANs users, in fact, are confusing between actual "roaming" and "portability". Portability is the ability to use the service in a given location, having the same functionality wherever the user is located, e.g. a laptop user that is able to access his corporate network from home or from his/her office. Roaming, instead, refers to the ability to move from one location to another without interruption in service or loss in connectivity, e.g. the user connected to the network through a PDA while traveling on the train. The key fact is that, while "portability" implies that the user is "standing" in one location (no matter wherever he/she is), "roaming" implies "moving" between one location to another. Through the adoption of the PPPoE layer, as illustrated in paragraph 3.2, Wireless LANs portability is not an issue: wherever the user is located, he/she can have his/her IP address and his/her personalised services. Roaming, also known as "handover", instead is more complex and requires that both the physical layer and the logical layer are synchronized to avoid service interruption or loss of connectivity. The IEEE 802.11 standard is a comprehensive standard that specifies the physical layer along with the medium access control protocol that nodes must implement in order to be able to communication with each other. The standard, however, does not specify routing, addressing, or handover issues, so that when a node moves between cells on different subnets it must terminate all its connections with the Internet and re-establish communications using its new IP address assigned in the new cell. Many manufacturer developed the handover feature between APs on the MAC sublayer, but the implementation do not cover the network layer, so that the APs must share the same network layer in order to avoid loss of connectivity (i.e. the APs must be connected to the same LAN or VLAN). Roaming, be it on wireless or wired LANs, motivated the development of Mobile IP [16], that enables mobile users to change their point of attachment to the Internet without changing their IP address and without losing its ability to communicate: that is the reason why some manufacturer are including Mobile IP implementations for use with the WLAN adapters and base stations. Although Mobile IP has been described for the Point-to-Point Protocol (PPP) in the RFC [17], the author suggests a simpler model. Such a model can easily fit in the VPDNs dial-up infrastructure of ISPs and mobile operators, with little effort. Some of the concepts used in the next paragraphs have been borrowed from the Global System for G. Paterno' Experimental [Page 11] Internet-Draft Using PPPoE in Wireless LANs February 2003 Mobile Communications (GSM), but there is no correspondence between Wireless LANs and the GSM world. It is also important to stress that the descriptions below refer to components and not devices: many components might be a single hardware device, and vice-versa. 4.1. Mobile Node (MN) The Mobile Node (MN) is the wireless node that is roaming from one AP to another. The MN can be any device that is WLAN capable, e.g. a PDA equipped with IEEE 802.11b. The decision to switch from one AP to another is mobile initiated, i.e. the wireless network adapter will to re-associate to another AP once the conditions applies, typically when falls out of the network coverage. These conditions are implemented by the wireless adapter manufacturer. 4.2. Wireless Access SubSystem (WASS) A single WASS is responsible of Mobile Nodes allocation and management on a given roaming location. The WASS will therefore interact with the MN at the Layer 2 of the OSI model, and it will take care of MN roaming within the location. The WASS is composed by one or more APs and one optional PPPoE Advanced Relay Agent (PARA). A single WASS is able to cover an entire building, or even a small campus: in such a scenario, the WASS is only composed by one or more APs, connected each other in the same LAN or VLAN. The PAC will then be directly connected to the WASS on the same ethernet segment of the APs (please refer to "native mode" in the PAC chapter). Most APs are able to manage roaming at the MAC layer, therefore APs will care about MNs roaming within the WASS. As the need of more roaming coverage area increases, e.g. an entire city or even nationwide, more WASSes are needed in the infrastructure. In such case, the PARA element is required in every WASS: the PARA will take care of the MN management by routing and forwarding PPPoE packets to/from a designated PAC. The paragraphs belows explores the two element of the WASS, i.e. the Access Point(s) and the PPPoE Advanced Relay Agent. 4.2.1. Access Point (AP) The Access Point (AP) is the device that is handling the radio interface of the Wireless LAN and, in most implementations, is acting as an ethernet "bridge". The AP is connected through the ethernet interface to the PARA or PAC and handles the handover process between APs in the PHY and MAC layers, i.e. it is caring about MNs handover at layer 2. All the APs in the same WiRAN must share the same Extended Service Set Identifier (ESSID) or group of ESSIDs. G. Paterno' Experimental [Page 12] Internet-Draft Using PPPoE in Wireless LANs February 2003 4.2.2. PPPoE Advanced Relay Agent (PARA) The PARA is the main system of the WASS: it is responsible of routing, forwarding and encapsulating PPPoE frames from the MN to the PAC and vice-versa, ensuring no service loss. The PARA is connected on one end to the same LAN/VLAN of the APs covering a given area, on the other to the PAC via IP (e.g. ethernet, token ring, ATM, etc...). Some manufacturers might implement the PARA function in their APs. The PARA is an advanced PPPoE Relay Agent: it has one or more Virtual MAC addresses (VMAC) configured on the APs side, with which communication occurs at MAC layer to and from the Mobile Nodes. A given VMAC represent a physical PPPoE server on the back-end: it is important that all PARAs within a given WiRAN have the same set of configured VMAC. By sharing the same VMACs across the WiRAN, the communication is not interrupted: when a MN switches from a WASS to another, thus changing the management PARA, the MAC address of the destination PPPoE server will remain unchanged. The PARA must be configured with a VMAC routing table, so that a given Virtual MAC corresponds to an IP address of a PPPoE server. PARA internal schema +------+ +----------------+ +--------+ | VMAC | | VMAC -> PAC IP | | | +------+ | Routing Table | | GRE | +------+ +----------------+ | | | VMAC | +----------------+ | Encap. | +------+ | Policy based | | | +------+ | MAC routing | | | | VMAC | | decision | | | +------+ +----------------+ +--------+ AP side PAC side (Ethernet) (IP based network) As a PPPoE frame enters the PARA, a routing decision occurs based on the destination MAC address and the frame is then encapsulated in a GRE [20] packet to the destination PAC. The GRE encapsulation carries the entire PADI, PADO, PADR, PADS and PADT messages within the payload, including ethernet MAC source and destination addresses. When a PPPoE frame is encapsulated, the PARA and PAC must set GRE's Protocol Type to the same value of the PPPoE ETHER_TYPE field, for example all PPPoE Discovery frames have GRE Protocol Type field set to the value 0x8863. For all the PPPoE ETHER_TYPE possible values, G. Paterno' Experimental [Page 13] Internet-Draft Using PPPoE in Wireless LANs February 2003 please refer to [1]. As the PARA is forwarding frames to and from the PAC, the SESSION_ID field of the PPPoE frames must not be changed. When a MN sends a PADI with the DESTINATION_ADDR set to the broadcast address, the designated PARA must analyse and forward the request to the selected PACs. PARA can decide if the packet has to be forwarded to all the configured PACs or part of them: this decision is based on its configured policies, e.g. the source MAC address or the ESSID to which the MN is associated (one AP can configure multiple ESSID). As the PACs is receiving the request, it must answer with a PADO with the DESTINATION_ADDR set to the unicast address of the MN that sent the PADI, and the SOURCE_ADDR set to the PAC's VMAC. The MN will select the PADO and sends one PADR packet to the Access Concentrator that it has chosen, for example the choice can be based on the AC- Name or the Services offered. The DESTINATION_ADDR field is set to the VMAC of the PAC that sent the PADO. All subsequential PPPoE packets will then have the MN MAC address and the VMAC as source/destination. 4.3. PPPoE Access Concentrator (PAC) The PPPoE Access Concentrator (PAC) is the PPPoE server that will handle the authentication, authorization, accounting, encryption and establish the network layer. It is recommended that the PAC sends MN's MAC address for authentication and management purposes to the authentication/authorization agent, e.g. the RADIUS server, in the form of Caller ID (CLID). It has to be noted that the PAC can act as an L2TP LAC, e.g. in a complex VPDN scenario: the advantage is that PPP frames are forwarded to the LNS (e.g. the customer) in an encrypted form, obtaining a full end-to-end security. The PAC has two different operational modes, based on the number of WASSes in the WiRAN: the "native mode" if the WiRAN is composed only by one WASS, or the "encapsulation mode". 4.3.1. Native mode "Native Mode" is only possible when a single WASS is used within the WiRAN, therefore no PARA is involved. The PAC is directly connected to the WASS (i.e. to the APs) through the ethernet medium and it comply to the PPPoE specification as in RFC [1]. G. Paterno' Experimental [Page 14] Internet-Draft Using PPPoE in Wireless LANs February 2003 The example below represent a typical architecture that is suitable for medium to large corporations, e.g. small campus or building: PAC | +------+---+---+------+ | | | | AP AP AP AP 4.3.2. Encapsulation Mode "Encapsulation Mode" is used when the WiRAN is composed by more WASSes, therefore the PARA element is in use. The PAC is responsible of encapsulating/decapsulating PPPoE frames in a GRE tunnel from/to the PARA, in order to virtualize the underlying network infrastructure. With such a flexible model, one or more PACs can handle a large scale WiRAN. The PAC is uniquely identified by a Virtual MAC and an IP address: both values must be configured in each PARAs' VMAC routing table to make it available for use. Once a packet is being sent from a PARA through the GRE tunnel, the PAC must decapsulate the PPPoE frame and check that the DESTINATION_ADDR is the PAC's VMAC or the broadcast address. The PAC will then update the MN MAC routing table with the MAC address of the MN and the source PARA IP address. The packet is then forwarded to the actual PPPoE server component and it will be processed accordingly. MN MAC routing table is needed to route back PPPoE frames to the correct PARA: as the MN is changing WASS (i.e. the PARA), a new packet will update the MN MAC routing table and the correct packet flow is ensured. As a new packet is encapsulated by the PPPoE server, the SOURCE_ADDR is set to the PAC's VMAC and DESTINATION_ADDR is set to MN MAC address, the destination MAC address then is looked-up on the MN MAC routing table and sent to the correct PAC through the GRE tunnel. G. Paterno' Experimental [Page 15] Internet-Draft Using PPPoE in Wireless LANs February 2003 PPPoE Access Concentrator Encapsulation Mode +--------+ +--------+ +-------------------+ +--------+ | | | | | MN MAC -> PARA IP | | | | GRE | | VMAC | | routing table | | | | | | | +-------------------+ | PPPoE | | Encap/ | | verifi | +-------------------+ | | | Decap | | cation | | Routing table | | Server | | | | | | update and | | | | | | | | Routing decision | | | +--------+ +--------+ +-------------------+ +--------+ PARA side Internet As described in chapter 5.3.2, the GRE encapsulation carries the entire PPPoE messages within the payload, including Ethernet MAC source and destination addresses. As described in [20], the GRE Protocol Type field contains the protocol type of the payload packet. These Protocol Types must be set to PPPoE ETHER_TYPE: based on the PPPoE type of packet, GRE Protocol Type must be set to 0x8863 (Discovery Stage) or 0x8864 (PPP Session Stage). Chapter 5.3.2 will also describe how PAC must handle PADI and PADO packets. The following logical schema represents a typical complex scenario that might be deployed in an ISP or mobile operator. AP AP AP AP | | | | AP -- PARA PARA -- AP | | | | | PAC | +-- PAC --+ | PAC | | | | | AP -- PARA PARA -- AP | | | | AP AP AP AP G. Paterno' Experimental [Page 16] Internet-Draft Using PPPoE in Wireless LANs February 2003 5. Conclusions At the time of writing, it is extremely easy for a malicious user to gain access to wireless networks, even if encrypted. Many Wireless LANs are unencrypted and their access points are configured to release dynamic IP address through the Dynamic Host Configuration Protocol. In such a configuration, it is even easier for an intruder to gain access to the network. Moreover, this raises some legal concerns: in some countries it is not illegal to gain access to a network that is not protected in any way or limited through a warning statement, for example through the usual "restricted area" banner, because the user is not accessing the Wireless LAN by "forcing" the system. Public services, such as mobile operators, ISPs, and free wireless networks, will not take advantage of any evolution of the WEP protocol. Today the encryption keys are unique for the whole Wireless LAN segment, which means that keys should be made publically available, in turn making the WEP protection mechanism ineffective. For consumers and corporations, using WEP or future protocols to encrypt "over-the-air" transmission is still an advantage: although easy to decrypt, the intruder should be very motivated to enter the network because an observation of thousands of interesting packets is needed to gain access to the encryption keys. Through this paper the author analyses the advantages of using Point- To-Point over Ethernet protocol as a solution for a Wireless LAN authentication layer: it has been demonstrated that, through the reuse of existing elements of the network and without changing the existing infrastructure, consumers, corporations and Internet Service Providers can take advantage of PPPoE, resulting in a more secure environment with no or little additional cost. G. Paterno' Experimental [Page 17] Internet-Draft Using PPPoE in Wireless LANs February 2003 Acronyms 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 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' Experimental [Page 18] Internet-Draft Using PPPoE in Wireless LANs February 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' Experimental [Page 19] Internet-Draft Using PPPoE in Wireless LANs February 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' Experimental [Page 20] Internet-Draft Using PPPoE in Wireless LANs February 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' Experimental [Page 21] Internet-Draft Using PPPoE in Wireless LANs February 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' Experimental [Page 22]