Internet-Draft Yoshihiro Ohba Expires: July, 2002 Subir Das Henry Haverinen Basavaraj Patil Phil Roberts Hesham Soliman Barani Subbiah January 28, 2002 PANA Usage Scenarios Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Many commercial networks today require users to provide their authentication information before being allowed access to network resources. Resources could include basic access to the network or could be more specific services in the network or a certain grade of service, etc. Currently, the authentication process depends upon the type of network that a user is attaching to and in most cases it is specific to an access technology. Therefore, a common protocol for performing user authentication (which is independent of access technologies) at the network layer (IP) or above is deemed necessary. This document attempts to capture various such scenarios where a higher layer protocol, such as, PANA (Protocol for carrying Authentication for Network Access) would be appropriate. The purpose of this draft is to help in understanding the problem space clearly, issues involved for different usage scenarios, and finally to facilitate the discussion for PANA requirements and framework. Expires July, 2002 [Page 1] Internet-Draft PANA Usage Scenarios January 28, 2002 Table of Contents 1 Introduction ............................................ 2 1.1. Requirements Language ................................... 2 1.2. Acronyms ................................................ 3 1.3. Terminology ............................................. 3 2. Current Mechanisms ...................................... 4 3. Scenarios Where PANA is Applicable ...................... 5 3.1. NAS ..................................................... 5 3.1.1. Layer Two Specific Network Access Mechanisms ............ 5 3.1.2. Multiple Access Routers ................................. 6 3.1.3. Multiple Interfaces on a Single Device .................. 8 3.1.3.1. Interface Switching ..................................... 8 3.1.3.2. Multi-homing ............................................ 9 3.1.3.3. Interface Sharing ....................................... 9 3.2. WLAN ................................................... 10 3.3. GPRS ................................................... 11 3.4. Intra-domain, Inter-technology Handoff ................. 11 4. LSA Usages ............................................. 12 4.1. Using LSA for Re-authentication ........................ 12 4.2. Using LSA for IKE ...................................... 12 5. Conclusion ............................................. 13 6. Acknowledgments ........................................ 13 7. References ............................................. 13 8. Authors' Information ................................... 14 1 Introduction Many commercial networks today require users to provide their authentication information before being allowed access to network resources. Resources could include basic access to the network or could be more specific services in the network or a certain grade of service (e.g., free vs. paid services), etc. Although authentication process varies from network to network, current best practices are to perform the authentication at the link layer. Since existing solutions are specific to access technologies, network providers need either a new transport mechanism or an extension to existing mechanism to authenticate users each time a new access technology is being standardized. A common protocol designed at the network layer (IP) or above could solve this problem. This document attempts to capture various scenarios where a higher layer protocol, such as, PANA (Protocol for carrying Authentication for Network Access) would be appropriate. The purpose of this draft is to help in understanding the problem space clearly, issues involved for different usage scenarios, and finally to facilitate the discussion for PANA requirements and framework. 1.1. Requirements Language 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 [Keywords]. Expires July, 2002 [Page 2] Internet-Draft PANA Usage Scenarios January 28, 2002 1.2. Acronyms AAA: Authentication, Authorization and Accounting AP: Access Point AR: Access Router DSL: Digital Subscriber Line GPRS: General Packet Radio Service ISP: Internet Service Provider NAS: Network Access Server PPP: Point-to-Point Protocol RADIUS: Remote Authentication Dial In User Service SA: Security Association WISP: Wireless ISP WLAN: Wireless Local Area Network 1.3. Terminology Following terminologies are defined for this document. Device A user's equipment (namely notebook computers, PDAs, etc.) that requires access to a provider's network. Local Network The immediate network(s) that is available to the device/user for Connecting. The network that the device is connecting to may be operated by anyone (not necessarily the users home network operator). PAA (PANA Authentication Agent) The functional element in the access network that a user device communicates with and provides it with the credentials used for authentication. PAA MAY also have an interface to AAA backend infrastructures for authenticating the device/user or may use any other authentication mechanism. PANA (Protocol for carrying Authentication for Network Access) A protocol which is used for carrying authentication information Expires July, 2002 [Page 3] Internet-Draft PANA Usage Scenarios January 28, 2002 between a device (acting on behalf of a user) and a PAA in order for the device to be allowed to access the network. Credentials Information that is transferred or presented to establish either a claimed identity or the authorizations of a system entity [RFC2828]. Credentials include things such as, private keys, trusted roots, tickets, or the private part of a Personal Security Environment (PSE) [RFC3157,RFC2510]. Initial Authentication Authentication performed by PAA when a device needs to be authenticated and authorized for network access. Re-authentication Authentication performed after successful initial authentication when a device needs to be authenticated again in order to extend the authorization lifetime for the network access. LSA (Local Security Association) A temporary security association between a device and a PAA, which is derived from a credential that is provided by the device on behalf of a user during initial authentication. 2. Current Mechanisms Today's technologies mostly rely on access specific mechanisms. For example, dial-up networks have relied on PPP's [RFC1661] capability to do user authentication in conjunction with AAA (RADIUS) [RFC2865] as a means to initial authentication. However, PPP may not be appropriate for most new type of networks. Moreover, node configuration through PPP is not always necessary. Today's wireless networks, especially cellular networks, also have relied on specific layer 2 identifiers and layer 3 messaging (NOT IP) to accomplish user authentication. Access control in most current technologies is performed on layer 2 based on device identification combined with layer 2 security. As new type of networks (including wireless LANs) are deployed in hotspot areas the legacy mechanisms may not be appropriate in such scenarios. Different kinds of service models are also emerging in today's Internet. For example, while basic connectivity may be user-agnostic, enhanced services will be available only to authorized users (since charging is involved for such services). The following scenarios are described in the next section: Expires July, 2002 [Page 4] Internet-Draft PANA Usage Scenarios January 28, 2002 - NAS - WLAN - GPRS - Intra-domain, inter-technology handoff 3. Scenarios Where PANA is Applicable 3.1. NAS Basic NAS functionality includes authentication of users with an authentication server. It has also hooks for access control. Although PPP offers these functionalities, it assumes few network characteristics: i) PPP always assumes a link layer disconnect indication. -- This feature is not available in networks such as Wireless LANs and others. So there has to be some mechanism to detect when the client disconnects. This might mean that there is also a need to re-authenticate client X to appear just after client A left, spoof the MAC and IP addresses of the client A, and basically continue to use client A's authenticated access. ii) Since PPP works in scenarios where dedicated links exist, it normally assumes a single access router in that link. -- However, this is not true in multi-access links, such as WLANs. Multiple ARs are required for efficient control and robustness. The multi-AR scenario is discussed in section 3.3. iii) PPP does address configuration to the client. -- Address configuration should be decoupled from AAA functionalities since in many cases devices may use other address configuration mechanisms such as DHCP, stateless address autoconfiguration, etc. In view of the above, we need a flexible NAS type of functionality. There are definitely architectural tradeoffs relating to the relationship between the PAA and the access control enforcement point in terms of their relative location (same box, or different box) as well as how close or far away from the client. Also there may be a need for defining some rules or policies on how this will interwork with L2 authentication and access control mechanisms, such as 802.1X and cellular systems. 3.1.1. Layer Two Specific Network Access Mechanisms WISPs are becoming prevalent and they are also starting Internet access services in public areas such as airports and hotel lobbies. The access control technologies they are currently considering would Expires July, 2002 [Page 5] Internet-Draft PANA Usage Scenarios January 28, 2002 be (i) web-based access control or (ii) L2 access control such as 802.1X. The web-based access control is performed at a higher layer after obtaining an IP address, whereas the L2 access control is performed before obtaining an IP address. There are pros and cons as to which layer access control is performed. However, a higher layer access control would be suitable for realizing user-agnostic network access services in which a user can access local information such as local-area map and flight information for free of charge, while access to specific external web-sites is subject to charge. The web-based access control could provide such a service, but there is no standard protocol or method which could help WISPs to support roaming users. While web-based access control can support devices with web browsers, there are number of other applications such as FTP, VoIP require a standard client application or protocol at the client. The client will use this protocol to initiate the network access for any non browser based applications. In addition to charge a user for external web access, a local WISP can also provide charge- based information delivery services such as music download, VoIP, etc. These services are provided by the local network and external connectivity is supported by gateways. It is also envisioned that NAS can be triggered either by the device or PAA, based on provider business model. PANA could provide a standardized way of L2-independent user-agnostic network access with roaming enabled. 3.1.2. Multiple Access Routers In multi-access environments such as Ethernet and 802.11a/b, it is possible for multiple ARs to exist on the same subnet. This is a fundamental difference from PPP in which a single AR is always associated with a PPP tunnel and the association never changes throughout the lifetime of the PPP connection. It would be desirable to use multiple ARs in such a way that traffic coming from and going to a specific device always goes through a single AR for ease of access control, but traffic among different devices diverges for the purpose of load balancing and redundancy. Although many NAS-based networks support multiple ARs for inbound traffic, however, for outbound traffic (originated from user devices connected via PPP tunnels to a single NAS) a single AR is always used. In an 802.11a/b network, it is possible to support multiple ARs if all first hop routers reside behind the layer-2 access points. On the other hand, if WLAN access points act as first hop access routers then it boils down to the same NAS type of model as described earlier. Thus in order to achieve load balancing and redundancy in a more flexible way we may need a different type of solution and in which case PANA seems to be appropriate. Consider the following scenario (see Fig.1 for IPv4 example): o Unlike the existing PPP-based NAS model, the device randomly (or by using some other criteria) selects one of the ARs as the Expires July, 2002 [Page 6] Internet-Draft PANA Usage Scenarios January 28, 2002 default router and always uses the selected AR as the next hop for the outgoing traffic. The network is also configured in such a way that ICMP Redirect would not occur in the edge subnet to avoid divergence of traffic coming from the user terminal. o Like the existing PPP-based NAS model, each AR has at least two interfaces, one (Ie) is attached to the edge subnet and the other (Ic) is attached to the core network. The subnet prefix assigned to Interface Ic covers that is assigned to Interface Ie. When an AR receives an address resolution request (ARP REQUEST or Neighbor Solicitation) from R (who is searching for the device on Interface Ic) the AR that is selected by the device replies to the address resolution request on behalf of the device and thereby guarantees that all incoming traffic going to the device passes through the AR. This part is the same as the existing PPP-based NAS scenario. For example, assume that devices D1 and D3 perform initial authentication with AR1 and that devices D2 and D4 perform initial authentication with AR2. If initial authentication is successful, AR1 and AR2 will open firewall and create proxy ARP (or ND) entries for D1/D3 and D2/D4, respectively. Packets originated from D1 or D3 are forwarded to AR1. Packets originated from D2 or D4 are forwarded to AR2. On the other hand, in terms of the reverse direction, when core router R receives a packet destined for either D1 or D2, it is delivered to the final destination through AR1 in the following way. If R does not yet have an ARP/Neighbor cache of the destination, it performs address resolution since it thinks that the destination is on-link according to the prefix assignment. Only AR1 makes a response to the address resolution request with specifying the MAC address of Ic1. Then, R forwards the packet to AR1 which delivers it to the final destination device. In the same way, when R receives a packet destined for either D3 or D4, it is delivered to the final destination through AR2. Expires July, 2002 [Page 7] Internet-Draft PANA Usage Scenarios January 28, 2002 [D1] ----+ | Ie1 Ic1 [D2] ----+---[AR1]---+ | Ie2 Ic2| [D3] ----+---[AR2]---+ | | [D4] ----+ | +---[R]---- [D5] ----+ | | Ie3 Ic3| [D6] ----+---[AR3]---+ | Ie4 Ic4| [D7] ----+---[AR4]---+ | [D8] ----+ D1..D8: Devices AR1..AR4: Access Routers R: Core Router Ie1 = x.y.1.1/24, Ic1 = x.y.0.1/16 Ie2 = x.y.1.2/24, Ic2 = x.y.0.2/16 Ie3 = x.y.2.1/24, Ic3 = x.y.0.3/16 Ie4 = x.y.2.2/24, Ic4 = x.y.0.4/16 Fig.1: A possible multi-AR environment In the above case, since both the incoming and outgoing traffic with regard to a specific device are controlled to pass though a single AR, it would be easier to perform authentication via the same AR. However, this would change if the topology is different or if traffic coming from and going to a specific device diverges among different ARs as a result of ICMP Redirect or the use of "Default Router Preferences and More-Specific Routes" [Draves] in IPv6. Detailed architecture tradeoffs will be discussed in framework document. 3.1.3. Multiple Interfaces on a Single Device PANA would be useful when a host has multiple interfaces of homogeneous or heterogeneous technologies. A typical example is a device with a Bluetooth interface and and an 802.11 interface or with multiple Bluetooth interfaces. There are three possible scenarios: interface switching, multi-homing, and interface sharing. 3.1.3.1. Interface Switching If multiple interfaces are connectable to the same local network, only one of those interfaces may be activated at a time for the purpose of battery saving, and perform interface switching when other interface is to be activated, with or without changing IP address. In such an environment, the device may have to perform initial authentication each time interface switching occurs, as well as periodical re-authentication for the activated interface. This would not be desired if initial authentication or re-authentication involves communication with the AAA infrastructure which would Expires July, 2002 [Page 8] Internet-Draft PANA Usage Scenarios January 28, 2002 increase AAA signaling traffic in the core network unless the user's credential is stored in the L2 network access point. The LSA established by using PANA as a result of successful initial authentication with an interface can be used for local re- authentication which would be performed periodically or at every interface switching event. See section "Using LSA for details. Note that this kind of optimization by PANA would not be possible if (i) multiple interfaces are connected to different local networks each managed by an independent PAA and (ii) re-authentication is not required. 3.1.3.2. Multi-homing If multiple interfaces are connectable to the same local network, those interfaces may be activated at the same time for the purpose of bandwidth increase and/or load balancing. In such an environment, the device may have to perform initial authentication multiple times, one for each interface, and periodical re-authentication for each interface. This would not be desired for the same reason described in section "Interface Switching". The LSA established by using PANA as a result of successful initial authentication with an interface can be can be shared among all the interfaces and used for local re-authentication which would be performed periodically or when an additional interface comes up. See section "Using LSA for Re-authentication" for details. Note that this kind of optimization by PANA would not be possible if (i) multiple interfaces are connected to different local networks each managed by an independent PAA and (ii) re-authentication is not required. 3.1.3.3. Interface Sharing There may be cases in which a device (i.e., a gateway device) has one provider interface and multiple private interfaces, where only the provider interface is connected to the ISP's local network and other interfaces are connected to other devices (child devices) under administration of the user (i.e., both the gateway device and child devices are owned by the same user). Traffic coming from the private interfaces would be bridged or routed to the provider interface and vice versa. Such a scenario would be more realistic in IPv6 where a /64 prefix could be allocated to the user, enabling a distinct IP address within the allocated prefix to be assigned to each of the devices of the same user. In terms of both access control overhead and AAA signaling overhead, it would be desirable to perform access control per prefix rather than per child device. PANA would be very suitable for such a prefix-based access control, especially in DSL or cable modem environment (see Fig.2). Expires July, 2002 [Page 9] Internet-Draft PANA Usage Scenarios January 28, 2002 [D1a] ----+ /64 prefix +--------+ | <-- | | [D1b] ----+---[GD1]--(DSL)-+ | | | | | | [D1c] ----+ | | | . +--+ AR +---- [D2a] ----+ . | | | | | | | [D2b] ----+---[GD2]--(DSL)-+ | | | | | [D2c] ----+ +--------+ GD1: Gateway Device of User 1 GD2: Gateway Device of User 2 D1a,D1b,D1c: Other Devices of User 1 D2a,D2b,D2c: Other Devices of User 2 AR: Access Router Fig.2: PANA usage in DSL In this usage scenario, it would be required to prevent other users from using the advertised prefix especially when the AR uses a single Ethernet interface for multiple gateway devices (i.e., multiple gateway devices of different users are on the same shared media, as shown in Fig.2). Details will be discussed in framework document. Note that if the gateway device and child devices are owned by different users, access control would be performed per-device instead of per-prefix. Then it boils down to one of the models as described earlier in which each device performs PANA with PAA. 3.2. WLAN WLAN is a one of the many scenarios where PANA could be useful. While 802.1X specification is being deployed by WISPs today, it would not meet the future needs such as inter-technology hand-offs, differentiation between free and paid access and others. While interworking with 802.1X needs to be taken into consideration, a solution at the higher layer is clearly another option, especially where only legacy 802.11a/b interface cards and APs are available. An alternative is that L2 authentication could be used to get free local access, and PANA could then later be used to access specific paid services or access to global Internet. PANA and 802.1X-based authentication together may not be required for all situations rather it would be preferable to use them in different places - 802.1X authentication is preferred in public operator networks where there are no free local services (or if all services are charged at a flat rate), and PANA is preferred in hotels and other places with free intranets. However, both mechanisms can coexist in a service provider's network since they belong to two different layers. Expires July, 2002 [Page 10] Internet-Draft PANA Usage Scenarios January 28, 2002 3.3. GPRS In GPRS there are only two methods of authenticating/acquiring an address from networks other than the GPRS access network (corporate or ISP). In one mode PPP is terminated by the GGSN which then authenticates the user (using the RADIUS client) to the "other" network, being the ISP the user connects to or the "home" corporate network depending on the requested APN. In the second mode, PPP is terminated in the MT, ONLY the Challenge Response is piggybacked on PDP context requests. The RADIUS client in the GGSN then relays this info to the RADIUS server wherever that maybe (Based on the APN). As yet another example, there is no mechanism for exchanging a second level of authentication and addressing information, only the interaction with the cellular systems' authentication and address assignment mechanism is possible (although Mobile IP could be used). A protocol that decouples the authentication and addressing from PPP (and Mobile IP) could allow an operator to provide remote authentication and authorization of home network services and address assignment within such a domain using one of the available IP layer tunneling mechanisms to deliver packets. 3.4. Intra-domain, Inter-technology Handoff Although the PANA WG will not directly work on solutions relating to mobility of the device. However, it is noted in the PANA WG charter that the ability to re-authenticate locally with the PAA, can be an important element in allowing efficient handling of mobile devices. This section describe possible situations where an LSA established by using PANA would be useful for mobile nodes. Different radio technologies will have different characteristics in terms of BW, cost, resilience and speed. Different applications may prefer to use access technologies that are most suited to their needs. It is foreseen that network operators will overlay different access technologies on top of their existing IP backbones to satisfy users' needs, hot spot coverages, etc. For an operator to have control over the access to their networks some mechanism for user authentication and access control is required. Currently these mechanisms are access dependent (e.g.,. HLR in GPRS and 802.1X specific mechanisms). Such access dependence requires an access dependent identity for the user. Hence while connected to a Cellular network, a user is identified by an IMSI, on a WLAN or Bluetooth network a user will have a different identity. For users to be able to roam seamlessly within an operator's domain between different access technologies they need to avoid re- authentication all the way back to their home AAA servers each time the move. Context Transfer (CT) may help, however if the identity of a user is different in each access technology, CT will not help and re-authentication will become necessary. Hence an access independent mechanism that uses a standard access independent identity is need to identify the user regardless of which access technology he/she is connected to. The LSA established by using PANA can be used for minimize the re-authentication overhead so that re-authentication is Expires July, 2002 [Page 11] Internet-Draft PANA Usage Scenarios January 28, 2002 performed only locally in a similar way that is described in section "Interface Switching". CT and MIP can solve the rest of the problem for seamless mobility. Another possible scenario in Mobile IPv6 is described in [Soliman]. 4. LSA Usages Establishing an LSA between a device and a PAA is equivalent to having a shared secret between them. The shared secret for the LSA can be derived from credentials of a user. The credentials could be a symmetric cryptographic key (i.e., shared key) or an asymmetric cryptographic key (i.e., public key). A typical example of symmetric cryptographic key is a password stored in the database of the user's home ISP. A typical example of asymmetric cryptographic key is a PKI digital certificate issued by a trusted 3rd party. 4.1. Using LSA for Re-authentication Once initial authentication is successful, re-authentication would be necessary in the following situations: o When there is a change in attributes of either the device or PAA. For example, re-authentication would be necessary when the device's IP address changes due to e.g., interface switching or handoff. o If the underlying access network does not have a capability to detect physical disconnection of devices, periodical re- authentication is necessary for (i) preventing connection hijacking from malicious users which would possibly occur when the device is shutdown or the user leaves the local network with the device without performing explicit log-off from the local network or (ii) improve the accuracy of accounting. On the other hand, it is desired that periodical re-authentication is performed locally between the device and PAA in order to minimize the signaling traffic. Once the LSA is established, re-authentication could be performed locally based on the shared secret for the established LSA. 4.2. Using LSA for IKE The shared key for the LSA or other shared key derived from the LSA can also be used as an IKE credential with which an IPsec SA between the device and PAA is established via IKE[RFC2409]. This would be useful especially in roaming environment where it is difficult to share the IKE credential a priori between the device and an IPsec entity in the local network. The established IPsec SA can be used for protecting PANA message exchange, which would be useful for quick re-authentication and/or Expires July, 2002 [Page 12] Internet-Draft PANA Usage Scenarios January 28, 2002 secure explicit log-off. It is also possible to utilize the LSA to establish an IPsec tunnel between a device and an IPsec gateway. The established IPsec tunnel can be used for protecting user data packets in the access network at the IP layer. This would provide access network security without relying on L2 security mechanisms, which is important considering the recent exposure of WEP vulnerabilities. 5. Conclusion The scenarios described above show a clear need for a common edge protocol that would provide network or service providers a vehicle for user authentication irrespective of what access technology they are using. It is anticipated that a higher layer solution like PANA can support future flexible service models. However, there are several issues that need to be resolved before we deploy this solution. We hope this draft will help the WG to understand different usage scenarios either existing or upcoming and the rationale behind this approach. 6. Acknowledgments The authors would like to thank James Kempf, David Spence, and the rest of the PANA Working Group for the ideas and support they have given to this document. 7. References [DIAMETER] P. Calhoun, et al., "Diameter Base Protocol", Work in progress, November 2001. [Draves] R. Draves, "Default Router Preferences and More-Specific Routes", Work in Progress, May 2001. [Keywords] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD 51), July 1994. [RFC2409] D. Harkins, et. al., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2510] C. Adams, et al., "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999. [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 2000. [RFC2865] C. Rigney, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Expires July, 2002 [Page 13] Internet-Draft PANA Usage Scenarios January 28, 2002 [RFC3157] A. Arsenault, et. al, "Securely Available Credentials - Requirements", RFC 3157, August 2001. [Soliman] H. Soliman, et al., "Security Association establishment for Mobile IPv6 Route Optimisation using AAA", Internet-Draft, Work in progress, July 2001. 8. Authors' Information Yoshihiro Ohba Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ 07961-0136 USA Phone: +1 973 829 5174 Fax: +1 973 829 5601 Email: yohba@tari.toshiba.com Subir Das MCC 1D210R, Telcordia Technologies 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com Henry Haverinen Nokia Mobile Phones P.O. Box 88 FIN-33721 Tampere Finland E-mail: henry.haverinen@nokia.com Phone: +358 50 594 4899 Fax: +358 3 318 3690 Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX. 75039 USA Phone: +1 972-894-6709 Email: Basavaraj.Patil@nokia.com Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA Phone: +1 847-202-9314 Email: PRoberts@MEGISTO.com Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 29, Kista, Stockholm 16480 Sweden Expires July, 2002 [Page 14] Internet-Draft PANA Usage Scenarios January 28, 2002 Phone: +46 8 7578162 Fax: +46 8 4043630 E-mail: Hesham.Soliman@era.ericsson.se Barani Subbiah 3Com Corporation 5400 Bayfront Plaza Santa Clara CA 95052 Email: barani_subbiah@3com.com Expires July, 2002 [Page 15]