INTERNET Draft Yoshihiro Ohba Expires: December 2001 James Kempf Phil Roberts Barani Subbiah Basavaraj Patil Henry Haverinen Hesham Soliman Usage Scenarios of a User Registration Protocol (URP) 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1.0 Abstract Many different kinds of commercial networks require users to perform registration before being allowed usage to resources. Resources could include basic access to the network to resources that are more specific such as services in the network or a certain grade of service, etc. The registration process is normally specific to the type of network that a user is attaching to and the registration process itself occurs in the protocol layers that are specific to an access technology. With a network layer (IP) or above solution, a common protocol for performing registration could be defined. 2.0 Introduction Many different kinds of commercial networks require users to perform registration before being allowed usage to resources. Resources could include basic access to the network to resources that are more specific such as services in the network or a certain grade of service, etc. The registration process is normally specific to the type of network that a user is attaching to and the registration process itself occurs in the protocol layers that are specific to an access technology. With a network layer (IP) or above solution, a common protocol for performing registration could be defined. This draft captures various scenarios that a common registration protocol can be applied to. The scenarios describe the current process that is defined for a specific technology and also show how a common protocol could benefit the same. Requirements can be derived from these scenarios. The intent of the draft is to clarify the technical requirements for an edge, user-network, registration protocol as well as to bring focus to the problem domain itself. 2. Terms 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 [Keywords]. 3.0 Current Mechanisms Today's technologies mostly rely on access specific mechanisms. For example, dial-up networks have relied on PPP's [2] capability to do user authentication in conjunction with AAA (RADIUS) [3] as a means to the process of user registration. 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 also have relied on specific layer 2 identifiers and layer 3 messaging (NOT IP) to accomplish user registration. 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 a user-pervasive service, enhanced services will be available only to authorized/registerd users (since charging is invovled for such services). 4.0 Scenarios where an edge registration protocol such as URP is applicable The following scenarios are described in this section: - NAS - WLAN - GPRS - Edge Protocol as a key distribution method for other protocols (MIPv6, SIP, IP Paging, etc) - Use of an edge protocol in assisting handoffs - Intra-domain movement between different access technologies - Others 4.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 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 Wireless LANs. Multiple access routers are required for efficient control and robustness. iii) PPP does address configuration to the client. -- Address configuration should be decoupled from AAA functionalities since in some cases it is necessary to be able to assign address prefixes to the client. In view of the above, we need a flexible NAS type of functionality. There are definitely architectural tradeoffs relating to the location of the authenticating entity (the BURP server when there is a separate BURP protocol) and the access control enforcement point, both in terms of their relative location (same box, or one or the other closer to the client) as well as how far away from the client they are located. Also there may be a need for a strategy on how this will interwork or use L2 authentication and access control mechanisms such as 802.1X and what is currently used in cellular systems. 4.1.1 NAS in an enterprise environment It is expected that network ports both wireless and wireline will be controled by some type of NAS. Even though, enterprise intranet is some what secured, it is very useful to control the network access by BURP or 802.1x to thwart any mallicious attempt by intruders. WLAN prolifiartion within enterprises is an impetus to deploy NAS in addition to other security mechansisms. While L2 based NAS can be useful, it can not meet different needs. For example, L2 based NAS can just disable or enable a port. However, it does not allow mutliple level of access with in a single port such as different access level for coroporate servers and net surfing. BURP is useful when a user connects multiple devices in a single port using a HUB, where a L2 NAS would require multiple access control. BURP like access control can also enable a enterprise to control access to vistors, employees and partners at different level. 4.1.1 Layer Two Agnostic Network Access Mechanisms Wireless ISPs (WISPs) are the current trend and they are starting Internet access services in public area such as airports and hotel lobbies. The access control technologies they are currently considering would be (i) web-based access control or (ii) L2 access control such as 802.1X. The web-based access control is similar to BURP in that they are performed at a higher layer after obtaining an IP address, whereas the L2 access control is performed before obtaining 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 schedule in free of charge, while access to external web-sites is subject to charge. The web-based access control could provide such a service, but there is no standardized method which would be required to support roaming among different WISPs. 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 access, a local WISP can also provide charge based services such as music download, VoIP. These services are provided by the local domain and external connectivity supported by Gateways. It is also envisioned that NAS can be triggered either by the client or network, based on provider business model. BURP will provide a standardized way of user-agnostic network access with roaming enabled. 4.1.2 Multiple Access Routers In multi-access environments such as Ethernet (not switched Ethernet) and 802.11a/b, it is possible for multiple Access Routers (ARs)to exist on the same subnet. This is a fundamental difference from PPP in which a single access router 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 user terminal always goes through a single AR for the ease of access control, but traffic among different user terminals diverges for the purpose of load balancing and redundancy. This is possible if the following conditions are met. o The user terminal randomly selects one of the ARs as the default router and always uses the selected AR as the next hop for the outgoing traffic. The network should be configured so that ICMP Redirect would not occur in the edge subnet to avoid divergence of traffic coming from the user terminal. o 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. The AR that is selected by the user terminal performs proxy ARP (in the case of IPv4) on behalf of the user terminal when it receives an ARP REQUEST on Interface Ic searching for the IP address assigned to the user terminal, which guarantees that all incoming traffic going to the user terminal passes through the AR. <-----BURP----><--Diameter/RADIUS--> [UT1] ----+ | Ie1 Ic1 [UT2] ----+---[AR1]---+----------[AAA server] | Ie2 Ic2| [UT3] ----+---[AR2]---+ | | [UT4] ----+ | +---[R]---- [UT5] ----+ | | Ie3 Ic3| [UT6] ----+---[AR3]---+ | Ie4 Ic4| [UT7] ----+---[AR4]---+ | [UT8] ----+ UT1..8: User Terminal AR1..4: Access Router co-located with Registration Agent 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, Ic2 = x.y.0.3/16 Ie4 = x.y.2.2/24, Ic2 = x.y.0.4/16 Fig.1: A possible multi-AR configuration In the above case, since both the incoming and outgoing traffic regarding the user terminal are controlled to pass though a single AR, it would be reasonable to put RA and AR within the same box. This usage is very similar to the current PPP-based NAS. If the above conditions are not met, traffic coming from and going to a specific user terminal may diverge among different ARs. This would happen as a result of ICMP Redirect or the use of "Default Router Preferences and More-Specific Routes" [Draves] in IPv6. In such cases, one RA would take care of multiple ARs so that it can update the access control list on each AR by using other protocol such as COPS, SNMP or Seamoby Context Transfer. Similar to the multiple ARs, it is possible that a RA can be implemented in an AP or a single RA can control multiple APs. COPS or SNMP can be used to update the control list at the APs if a RA controls mutiple APs. 4.1.3. Multiple Interfaces on a Single User Terminal BURP would be useful when a host has multiple interfaces of homogeneous or heterogeneous technologies. A typical example is a user terminal 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. 4.1.3.1. Interface Switching If multiple interfaces are connectable to the ISP 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, if all we haveis L2 authentication, the user terminal would have to perform AAA with the home AAA server each time interface switching occurs. Since BURP is independent of L2 technology, the BURP LSA established at the time of initial access time via AAA with the home AAA server can be applied for future interface switching. 4.3.1.2. Multi-homing If multiple interfaces are connectable to the ISP network, those interfaces may be activated at the same time for the purpose of bandwidth increase and/or load balancing. In such an environment, if all we have is L2 authentication, the user terminal would have to perform multiple sets of AAA with the home AAA server, one for each interface. Since BURP is independent of L2 technology, the LSA established at the time of initial access time via AAA with the home AAA can be shared among multiple interfaces. 4.3.1.3. Interface Sharing There may be a case in which a user terminal (a gateway user terminal) has one provider interface and multiple private interfaces, where only the provider interface is connected to the ISP and other interfaces are connected to other user terminals under administration of the 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 user terminals 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. BURP is very suitable for such a prefix-based access control, especially in the following DSL scenario (see Fig.2). o The RA is co-located with the AR. o Before BURP registration is successful, only the link-local address is available on the provider interface of the gateway user terminal. The gateway user terminal performs BURP registration by using the link-local address. o If BURP registration is successful, a /64 prefix is assigned to the registered user, and the AR starts to advertise, by using ICMPv6 Router Advertisement, the /64 prefix on the link to which the gateway user terminal is connected. It is possible for either the AR or AAA server to be the entity that assigns the /64 prefix to the user (the latter case is shown in Fig.2). In order to prevent other users from listening to the advertised prefix and using it, it would be desirable for the AR to have physically separated interface for each user as shown in Fig.2. BURP Diameter/RADIUS <--------------> <-------------> [UT1a] ----+ +--------+ | | | [UT1b] ----+---[GUT1]--(DSL)--| +------[AAA server] | <-- | | <-- [UT1c] ----+ /64 prefix| | /64 prefix | AR | [UT2a] ----+ | | | | | [UT2b] ----+---[GUT2]--(DSL)--+ +------[R]---- | | | [UT2c] ----+ +--------+ GUT1: Gateway User Terminal of User 1 GUT2: Gateway User Terminal of User 2 UT1a,UT1b,UT1c: Other User Terminals of User 1 UT2a,UT2b,UT2c: Other User Terminals of User 2 AR: Access Router co-located with Registration Agent R: Core Router Fig.2: BURP usage in DSL (IPv6 /64 prefix assignment by AAA Server) 4.2 WLAN WLAN is a one of the many scenarios where BURP could be useful. While 802.1x specification is being deployed by WLISPs today, it does not meet the future needs such as intertechnology hand off, differentiation bewteen free and charge accesss and others. While interworking with 802.1x needs to be taken into consideration, a solution at the highrlayer is clearly another option. An alternative is that L2 authentication could be used with the actual user credentials to get free local access, and BURP could then later be used to access any chargeable services or global Internet. It's also possible that BURP and L2 authentication will not be used together for network access authentication but rather they are useful in different places -- L2 authentication is great in public operator networks where there are no free local services (or if all the services are charged at a flat rate), and BURP is good in hotels and other places with free intranets. Mobile IPv6 will be an important protocol in WLANs and WLAN/cellular multi access networks. In IPv4, MN-AR AAA is handled by Mobile IP itself, but there is some amount of agreement within the Mobile IP working group that this solution was adopted out of necessity and a better solution would be to have AAA handled by a lightweight protocol designed specifically for host/edge network element AAA communication, as Diameter is designed for communication between AAA elements within the network. BURP could serve such a function. 4.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" coporate 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 MIP) 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. 4.4. Edge Protocol as a key distribution method for other protocols There are a number of protocols that locate an "agent" in the network in order to deliver data packets to, or exchange protocol-specific signaling messages with, the user terminal. Mobile IP, IP Paging and SIP are examples of such protocols. Any of those agent-based protocols have a requirement or a recommendation to have a Security Association (SA) between a user terminal and an agent, which is used by the agent and the user terminal to authenticate and/or encrypt signaling messages exchanged between them. The important point is that in wireless roaming environment, it is usual that the user terminal may not have a pre-established SA with the agent of each protocol in the visiting domain, and hence it is required to authenticate the "previously-unknown" peer when establishing an SA with it. There are basically two approaches to authenticate a previously-unknown peer. One approach is using PKI together with an SA establishment protocol. IKE [RFC2409] with the use of PKI certificate is one example. However, the PKI-based approach would be heavyweight because of the complexity on iterative calculation of public-key cryptography and the process needed for checking the certificate revocation status. The other approach is utilizing some other pre-established SA, directly or indirectly, to derive a new SA. Since BURP assumes the existence of a pre-established SA between the user and home AAA server, it is possible to use the pre-established SA for that purpose. 4.4.1. Generic BURP-based key distribution scenario A generic BURP-based key distribution scenario is described in the following way: 1) The user terminal performs BURP registration. If the registration is successful, an LSA is established between the user terminal and RA. The shared secret for LSA is derived from the pre-established SA between the user and home AAA server. 2) When the user terminal needs to have a new SA with an agent of a protocol, it sends a BURP message containing a key request specifying at least the address of the agent. 3) If the RA receives the key request, it generates a new key and returns a BURP message to the user terminal with a copy of the generated key encrypted by using the shared secret for the LSA. The RA also creates another copy of the key and deliver it securely to the agent address specified in the key request via other protocol such as SNMP and COPS, with the use of either built-in security mechanism or a secure transport. 4) When the BURP LSA is deleted due to disconnection of the user terminal, the RA executes a procedure to invalidate the distributed keys. To realize this, any BURP message exchanged after establishing the LSA is expected to be encrypted between the user terminal and RA by using the LSA. In addition, a pre-established SA would be necessary between the RA and each agent of each protocol. Note that it is also possible to use the delivered key as a pre-shared key used by an out-of-band key management protocol such as the IKE [RFC2409] to authenticate the key exchange sequence. 4.4.2. Protocol-specific issues 4.4.2.1. Mobile IPv4 In Mobile IPv4 [RFC2002] there are two kinds of agents: Home Agent and Foreign Agent. Since Mobile IPv4 has a built-in key distribution mechanism coupled with AAA [Regkey,Diameter-MIPv4], BURP-based key distribution would not be necessary for Mobile IPv4. Such a built-in key distribution mechanism would also apply to MIPv4 extensions used for enhancement of handoff performance [Regreg,Low-latency]. 4.4.2.2. Mobile IPv6 In the base protocol of Mobile IPv6 [MIPv6] there is only one kind of agent: Home Agent. MIPv6 Binding Update is authenticated by using BSA (Binding Security Association). A MIPv6 extension [HMIPv6] used for supporting hierarchical mobility management defines an additional mobility agent called MAP (Mobility Anchor Point), and it is also necessary to authenticate Binding Update exchanged between Mobile Node and MAP. Another MIPv6 extension [Fast-MIPv6] defines a new destination option called Fast Binding Update which also required to be authenticated in the same way as the standard Binding Update. Unlike MIPv4, all these protocols do not have build-in key distribution mechanism. Thus, it is possible to utilize BURP as a tool to establish a BSA between a Mobile Node and a MIPv6 mobility agent, as the SA is expected to be coupled with AAA. Note that regarding a BSA between a Mobile Node and Correspondent Node, it might not be necessary for key distribution to be couple with either AAA or PKI. Instead, a different key distribution mechanisms as described in PBK [PBK] and HIP [HIP] have been considered for such SAs. 4.4.2.3. IP Paging IP paging [RFC3132,Paging-req] defines four types of functional elements: Paging Agent (PA), Tracking Agent (TA), Dormant Monitoring Agent(DMA) and Host. There is a requirement that signaling messages exchanged among those elements are authenticated in order to avoid a couple of security attacks such as bogus paging registration, bogus paging area advertisement and bogus paging messages. It is possible to utilize BURP for establishing SAs between Host and PA, Host and TA, and Host and DMA, to the Host, if those SAs are expected to be coupled with AAA. 4.4.2.4. SIP SIP [RFC2543] defines SIP proxy server, SIP redirect server and SIP registrar that act as agents communicating with SIP Usage Agents, and such communication would be authenticated. Several scenarios regarding SIP interaction with AAA are described in [SIP-AAA,SIP-reg]. If BURP is used for SIP session key distribution, it is possible to simplify the SIP-AAA interaction since SIP can operate as if there is a pre-shared key between the User Agent and SIP proxy/redirect/registrar. 4.5 Use of an edge protocol in assisting handoffs There are a couple issues involved in mobility that a lighweight, MN to network admission control protocol such as BURP could accomplish. Here are some suggestions. 1) One major issue with handover is that setting up network parameters in the new subnet can be extremely time consuming. QoS is an example. The COPS signaling involved in moving an RSVP reservation from one access router to another is almost as large if not larger than the actual RSVP signalling itself. At the level of the Access Router, this problem can be simply solved with context transfer. Context such as QoS, authentication, etc. is transfered from one Access Router to another, allowing the MN to quickly start with exactly the same basic network service context as in the old subnet. But some of this context is not confined to the edge network. Authentication and header compression are, QoS clearly isn't. One way BURP could help is if the initial BURP transaction resulted in the MN getting a kind of encrypted capabilities token which did two things: a) Identified the MN to the network independently of the IP address, b) Identified what rights the MN has to basic network services such as QoS. This token could be used in a number of ways. One way, as mentioned, is to allow the MN to propagate basic network context beyond the edge subnet. The MN includes the token in a header extension to allow QoS reservations to happen back in the network (note: this will require some co-ordination with the NSS /// NSIS ? working group). With the token, the same router that is the PDP also acts as a PEP. The alternative here is that the Seamoby context information is propagated into the network by the Access Router. Unless flooding is used, this will not notify routers on the path of new packet streams what the MN's rights to basic network services are. In addition, it may also not be possible to propagate this context outside of the local domain. A capabilities token in the MN's header could be used end to end, though it would require some cross-domain agreement on the capabilities. The token could also be used to anonymously identify the MN. Because the token uniquely identifies the MN without reference to the IP address, it could be used as an anynonmiser. The MN IP address (probably CoA for MIP) could be randomly assigned and if the packet contents are encrypted, the MN can't be traced any further than the edge subnet where the IP address/CoA is, but the network can still identify that the MN has rights to use it via the token. The tokin in this case functions very much like a Purpose Built Key (PBK, please see the PBK draft by Bradner and Mankin). This token could also be used for periodic lightweight reauthentiction. The BURP RA issues a lightweight challenge and the MN responds with the token. 2) Another issue that has come up in the Seamoby working group is Access Router selection. Seamoby is working on a target Access Router selection protocol. In order to allow for good handover performance, it is probably better to have the MN negotiate its preferences for Access Routers having particular characteristics (like cost, bandwidth, etc.) upon admission to the network rather than at the actual time of handover. These preferences would then be propagated by context transfer as the MN moved, avoiding the need for any radio traffic during handover. The details of what actually gets negotiated are probably outside of BURP's charter, but the framework for negotiating it and also perhaps for defining what gets negotiated may be part of it. 3) RA-RA to NAS profile transfer. During the hand off, MN will try to associate itself with the new RA for NAS in the new network or in the same network (if it is not controlled by the same RA). In order to avoid delays, NAS profile of the user should be transferred to new RA during the hand off. This will allow the new RA, to admit traffic from the MN with out a new NAS challenge. It is possible that the RA profile could contain the new CoA (fast hand off) so that the new RA can admit MN traffic with out any delay. If RA is in the same AR where seamoby context transfer takes place, then BURP profile can be part of seamoby context transfer. If RA and AR are different then RAs should use contaxt transfer protocol to transfer NAS profiles. 4.6 Intra-domain movement between different access technologies Different radio technologies will have different characteristics in terms of BW, cost, resilence and speed. Different applications may prefer to use access technologies that are most suited to their needs. It is foreseen that nework 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 dependant (eg. HLR in GPRS and 802.1X specific mechanisms). Such access dependance requires an access dependant identity for the user. Hence while connected to a Celluar 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 each time the move. 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 independant mechanism that uses a standard access independent identity is need to identify the user regardless of which access technology he/she are connected to. CT and MIP can solve the rest of the problem for seamless mobility. 5.0 Conclusion The scenarios above show a need for a common edge protocol that would enable the consolidation of various types of approaches in one. It would also make network access uniform irrespective of the access technology. There are many issues that need to be considered in the design of a common edge protocol but this draft profiles scenarios that warrant the development of such a protocol. 6.0 Acronyms GPRS General Packet Radio Service DSL Digital Subscriber Line CT Context Transfer NAS Network Access Server 7.0 References [Draves] "Default Router Preferences and More-Specific Routes", draft-ipngwg-router-selection-00.txt, Work in Progress, May 2001. [Keywords] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2409] D. Harkins, et al., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2002] C. Perkins, "IP Mobility Support", RFC 2002, Octover 1996. [Regkey] C. Perkins, et al., "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-07.txt, Work in progress, July 2001. [Regreg] E. Gustafsson, et al., "Mobile IP Regional Registration", draft-ietf-mobileip-reg-tunnel-04.txt, Work in progress, March 2001. [Low-latency] K. El Malki, et al., "Low Latency Handoff in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt, Work in progress, May 2001. [Diameter-MIPv4] P. Calhoun, et al., " Diameter Mobile IPv4 Application", draft-ietf-aaa-diameter-mobileip-06.txt, Work in progress, June 2001. [MIPv6] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-14.txt, Work in progress, July 2001. [HMIPv6] H. Soliman, et al., "Hierarchical MIPv6 mobility management", draft-ietf-mobileip-hmipv6-03.txt, Work in progress, February 2001. [Fast-MIPv6] G. Tsirtsis, et al., "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-01.txt, Work in progress, April 2001. [PBK] S. Bradner, et el., "A Framework for Purpose Built Keys (PBK)", draft-bradner-pbk-frame-00.txt, February 2001. [HIP] R. Moskowitz, "Host Identity Payload And Protocol", draft-moskowitz-hip-03.txt, Work in progress, February 2001. [RFC3132] J. Kempf, "Dormant Mode Host Alerting ("IP Paging") Problem Statement", RFC 3132, June 2001. [Paging-req] J. Kempf, et al., "Requirements and Functional Architecture for an IP Host Alerting Protocol", draft-ietf-seamoby-paging-requirements-01.txt, Work in progress, May 2001. [RFC2543] M. Handley, et al., "SIP: Session Initiation Protocol", RFC 2543, March 1999. [SIP-AAA] H. Basilier, et al., "AAA Requirements for IP Telephony/Multimedia", draft-calhoun-sip-aaa-reqs-02.txt, Work in progress, May 2001. [SIP-reg] H. Schulzrinne, "SIP Registration", draft-schulzrinne-sip-register-01.txt, Work in progress, April 2001 8.0 Author Contact 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 James Kempf Sun Microsystems 901 San Antonio Rd., MTV29-235 Palo Alto, CA 94303 USA Phone: +1 650 336 1684 Fax: +1 650 691 0893 Email: james.kempf@sun.com Barani Subbiah 3Com Corporation 5400 Bayfront Plaza Santa Clara CA 95052 Email: barani_subbiah@3com.com Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA Phone: +1 847-202-9314 Email: PRoberts@MEGISTO.com Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX. 75039 USA Phone: +1 972-894-6709 Email: Basavaraj.Patil@nokia.com Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 29, Kista, Stockholm 16480 Sweden Phone: +46 8 7578162 Fax: +46 8 4043630 E-mail: Hesham.Soliman@era.ericsson.se 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