INTERNET DRAFT Henrik Basilier Category: Informational Ericsson, Inc. Title: draft-calhoun-sip-aaa-reqs-04.txt Pat R. Calhoun Date: March 2002 Black Storm Networks Matt Holdrege ipVerse Tony Johansson Ericsson, Inc. James Kempf Sun Microsystems, Inc. Jaakko Rajaniemi Nokia Networks AAA Requirements for IP Telephony/Multimedia 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. This document is an individual contribution for consideration by the SIP Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@diameter.org mailing list. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2001. All Rights Reserved. Calhoun et al. expires September 2002 [Page 1]
INTERNET DRAFT Feb 2002 Abstract The AAA Working Group has been defining requirements for Network Access in Inter-Domain (roaming) networks, including requirements from the Mobile IP and NASREQ Working Groups. Some of these requirements were input from work done in the 3rd Generation wireless SDOs. These same SDO's have a need to tie their IP Intelligent Servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their AAA infrastructure. This Internet Draft describes requirements from 3rd Generation wireless SDOs, discusses an architecture that satisfies those requirements and deduces requirements for detailed definition of SIP- AAA interworking. Furthermore, the Draft is intended to stimulate discussions within the SIPPING Working Group, in order to come up with a set of requirements that could then be used to begin informative protocol design (meaning a new application extension to Diameter) in the AAA Working Group. Table of Contents 1.0 Introduction 1.1 Requirements language 1.2 Abbreviations 2.0 Network Architecture 2.1 Prerequisites for the 3G SDOs 2.2 Registration 2.3 Invitation 2.3.1 Invitation terminating in the mobile node 2.3.2 Invitation originating from the mobile node 2.3.3 Session accounting 3.0 Requirements 4.0 Security Considerations 5.0 References 6.0 Acknowledgements 7.0 Authors' Addresses 8.0 Full Copyright Statement Calhoun et al. expires September 2002 [Page 2]
INTERNET DRAFT Feb 2002 1.0 Introduction The AAA Working Group has been defining requirements for Network Access in Inter-Domain (roaming) networks, including requirements from the Mobile IP and NASREQ Working Groups. Some of these requirements were input from work done in the 3rd Generation wireless SDOs. These same SDO's have a need to tie their IP intelligent servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their AAA infrastructure. This Internet Draft describes requirements from 3rd Generation wireless SDOs, discusses an architecture that satisfies those requirements and deduces requirements for detailed definition of SIP- AAA interworking. Furthermore, the Draft is intended to stimulate discussions within the SIPPING Working Group, in order to come up with a set of requirements that could then be used to begin informative protocol design (meaning a new application extension to Diameter) in the AAA Working Group. 1.1 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. 1.2 Abbreviations 3GPP: Third Generation Partnership Project 3GPP2: Third Generation Partnership Project 2 AAA: Authentication, Authorization and Accounting DNS: Domain Name Server DSI: Dynamic Subscriber Information database SDO: Standard Development Organization SIP: Session Initiation Protocol Calhoun et al. expires September 2002 [Page 3]
INTERNET DRAFT Feb 2002 2.0 Network Architecture This section describes details of a scalable network architecture based on SIP using a backend AAA infrastructure for use in 3G and possibly other wired and wireless networks. We will detail how the registration procedure will occur. We will also investigate how a SIP invitation will proceed. The authors wish to state that much of this work is still in progress in various other groups including the SIP WG and 3G SDOs, and is subject to change. The ideas described in this document do not represent a final agreement in any working group or SDOs, but does include ideas from well established positions in the related groups. This document will be updated when further SIP, AAA, and 3G requirements are received. This document is also intended as an informal method for IETF SIP experts to feed in their expertise into the 3G standardization efforts through comments on this Internet Draft. Although the next generation wireless networks (3G) are a driving force towards the integration of SIP and AAA, it is desirable that the architecture proposed be similar, if not identical, to the wireline architecture. 2.1 Prerequisites for the 3G SDOs The usage of SIP and Diameter within 3GPP and 3GPP2 is or is expected to be specified in the respective SDOs, which set some prerequisites on the interworking between the 3G SDOs SIP architecture and the AAA infrastructure. There is a separate discussion about the way 3GPP and 3GPP2 defines the usage of SIP. This document focuses only on SIP - AAA related issues. The following requirements are identified due to the perceived need of evolving existing telecommunications infrastructure rather than build new independent ones as well as the need to solve problems identified with existing systems: 1. It is required that the home network always maintain the control of sessions and services because service mobility can be easier realized. 2. Scalability of the architecture is required. This will minimize deployment issues when SIP servers are added to the network to relieve traffic load. Calhoun et al. expires September 2002 [Page 4]
INTERNET DRAFT Feb 2002 3. The distributed architecture of the 3G network shall be hidden from the user. Thus a user must not be tied to a particular SIP server. 4. Performance considerations: the operational architecture of hosts that serve many users shall be kept as simple as possible. Resource consuming operations shall be dedicated to servers that can implement load sharing. 5. Necessity of SIP-AAA interworking: A 3GPP or 3GPP2 operator requires its SIP servers to have access through AAA to subscriber information so that they can request authorization and authentication information before granting access to the user to the multimedia services he or she may have subscribed to. An operator may therefore want the possibility to restrict the usage of SIP servers to authorized users only. Accounting may be used to gather usage data of SIP servers for a specific user. 6. Multiple access networks may exist: authorization based on the authorization from the access network does not guarantee access rights for SIP services. 2.2 Registration In this section, we will provide an example of a user registering his device. The scenario described is one where the user is roaming in a visited network, typically owned and operated by a different service provider. This is however seen as a superset of the scenario where the user is in his home network, which is therefore not explicitly described. As stated in section 2.1, it is a requirement that a user MUST not be tied to a specific SIP server. This is necessary for many reasons, including scaling and to minimize deployment issues when SIP servers are added to the network to relieve traffic load. In this document, the SIP server that has been either statically or dynamically assigned to serve a particular user is called the Serving SIP Proxy in the home network. This document assumes that the Serving SIP Proxy is always assigned in the home network of the user. One other important consequence from the requirements in section 2.1 is the ability to have a Home entry SIP Proxy, acting as a SIP proxy. The Home entry SIP Proxy will access a Dynamic Subscriber Information (DSI) database through the AAAH in order to identify the Serving SIP Proxy in the home network serving the particular user. This Home entry SIP Proxy MAY be used both for incoming SIP Sessions (SIP INVITEs originating in another network) as well as messages Calhoun et al. expires September 2002 [Page 5]
INTERNET DRAFT Feb 2002 originating from roaming mobiles (accessing functions in their home network from a different domain/provider) if there was a desire to hide the network configuration. If there was no desire to hide the network configuration the SIP INVITEs MAY be originated directly to the Serving SIP Proxy in the home network. Furthermore, a Outbound SIP Proxy in the Visited network MAY be present. The Outbound SIP Proxy is the first point of contact in the visited network for a multimedia user. The Outbound SIP Proxy behaves like a Proxy (as defined in [1] or subsequent versions), i.e. it accepts requests and processes them internally or forwards them on to the Home entry SIP Proxy, possibly after translation. There could be several methods for a mobile node to find its Home entry SIP Proxy / Outbound SIP Proxy or for any other node to find the Home entry SIP Proxy Contact of a user. Although the exact methods to use is outside the scope of this document, we have assumed the use of Domain Name Service (DNS) throughout this document. Calhoun et al. expires September 2002 [Page 6]
INTERNET DRAFT Feb 2002 Home Network +--------+ +----------+ +------->|xyz.com |<----->| xyz.com | | | AAAH |<--+ | DSI | | +--| server +-+ | | Database | | | +--------+ | | +----------+ | | | | 6.AAA|7.AAA| 4.AAA| |3.AAA Req| Rsp| Rsp| | Req | v v | +--+--------+ 5. SIP +---+---------+ |Serving SIP| Reg.| Home | | Proxy in |<-------+ entry | | the home | | SIP | | network +------->| Proxy | +-----------+8.200 OK+--+----------+ | ^ | | 9.200 OK| | 2. SIP REGISTER v | +-------+--------+ | (optional) | Visited Network | Outbound | | SIP | | Proxy | +--+-------------+ | ^ 10.200 OK | | 1. SIP REGISTER v | +-------+-+ | SIP | | Client | bob@xyz.com +---------+ Figure 1: SIP Registration In the event an Outbound SIP Proxy is present, a SIP client issues its SIP REGISTER method to the Outbound SIP Proxy within the visited network, otherwise the message is sent directly to the Home entry SIP Proxy. When present, the Outbound SIP Proxy forwards the SIP REGISTER to a Home entry SIP Proxy in the home network of the user. When the Home entry SIP Proxy receives SIP REGISTER method from the SIP client or the Outbound SIP Proxy, the Home entry SIP Proxy will issue a AAA message to the Home AAA Server (AAAH). The AAA message includes the SIP Client's identity, relevant parameters from the SIP message, and other authorization and service specific information. The AAAH MAY use the information to authenticate the SIP client, and to determine whether it authorizes the client to access the service. Calhoun et al. expires September 2002 [Page 7]
INTERNET DRAFT Feb 2002 The AAAH MAY decide that a challenge-response procedure is appropriate, and instruct the SIP proxy to send back a 401 (Unauthorized) response. The AAAH would generate the challenge in the response message that is sent back in to the SIP client, which would then have to re-register. If access is granted, the AAAH must verify whether a static Serving SIP Proxy in the home network was configured for the client or if one was selected by the Home entry SIP Proxy. If an Serving SIP Proxy in the home network has not been selected, the AAAH MAY dynamically assign an Serving SIP Proxy in the home network to the SIP client, who will act as the client's server for the duration of the authorization period (determined by the AAAH) or the Home entry SIP Proxy MAY select a Serving SIP Proxy in the home network for the user (selection based on information obtained from the AAA server). If the AAAH determines that the SIP client does not have a security association with the assigned server, it MAY create a dynamic security association between the nodes, by distributing session keys to be used in all subsequent SIP messages. This is similar to the method described in [4]. Dynamic establishment of security associations by the AAAH is typically useful in scenarios where the entities do not have pre- established trust, and trust is mandatory in all SIP messages. It should be equally possible for the AAAH to return the relevant certificates to the entities, which could then establish a direct security association, via an out-of-band key management protocol, such as the Internet Key Exchange [8]. When the Home entry SIP Proxy has obtained a successful reply from the AAAH the Home entry SIP Proxy will forward SIP REGISTER method to the selected Serving SIP Proxy in the home network. At this point the Serving SIP Proxy in the home network MAY pull security information (e.g. Session keys) and other necessary information (e.g. Service Profile) from the AAAH. If the Home entry SIP Proxy has selected the Serving SIP Proxy in the home network for the user, the Serving SIP Proxy in the home network MAY also request to the AAAH that it updates the DSI database to include the identity of the Serving SIP Proxy. If the AAAH has authenticated the client the Serving SIP Proxy in the home network will then responds back to the Home entry SIP Proxy with a 200 OK message, which is proxied back all the way to the user. If the authentication of the SIP client is instead handled by the Serving SIP Proxy in the home network, the Serving SIP Proxy in the Calhoun et al. expires September 2002 [Page 8]
INTERNET DRAFT Feb 2002 home network MAY decide that a challenge-response procedure is appropriate, and MAY issue a 401 (Unauthorized) response, including the challenge. The SIP client would calculate the answer to the challenge and would have to re-register and if granted, then the Serving SIP Proxy in the home network will send back a 200 OK message. The AAAH MAY push security information (e.g Session keys) along with other necessary information (e.g Service profile) to the assigned Serving SIP Proxy in the home network. This sequence is not illustrated in any of the figures. A successful SIP registration MAY result in the generation of an accounting record by the client's Serving SIP Proxy in the home network. The accounting record MAY include such information as the user's identity, the location of the registration, date and time, etc. Once the AAAH has sent the successful authorization message to the Serving SIP Proxy in the home network, it MAY update its DSI database. The database contains the identity of the SIP client, and the Serving SIP Proxy in the home network. This database MAY be used by other SIP servers within the local administrative domain to identify a SIP client's assigned SIP server. Additionally, under certain circumstances (e.g., subscription termination, lost terminal, etc.), a home network administrative function may determine a need to clear a user's SIP registration and the assignment of the Serving SIP Proxy in the home network. This function initiates the de-registration procedure and may reside in various elements depending on the exact reason for initiating the de- registration. One such home network element is the AAAH. Also an administrative function external to the AAAH may trigger the AAAH to initiate the de-registration procedure. 2.3 Invitation In this section, we will look at the details of a SIP INVITE message, how a session is setup, and how accounting takes place for the session. It is assumed that there will be some kind of security association between SIP servers. This may be established either via the AAA infrastructure or in some other way to allow SIP sessions to be established from SIP servers / proxies that are not members of the AAA infrastructure on behalf of other users. 2.3.1 Invitation terminating in the mobile node Calhoun et al. expires September 2002 [Page 9]
INTERNET DRAFT Feb 2002 Home Network +--------+ +----------+ +----------+ |xyz.com | | xyz.com | | Naming | | AAAH |<-->| DSI | | Server | +->| server | | Database | | (e.g.DNS)| | +--------+ +----------+ +----------+ | ^ ^ | AAA | | | | | xyz.com? v V v +-----------+ INVITE+-----------+ INVITE +-----------+ |Serving SIP|<------+ Home |<-------+ abc.com | |Proxy in | | entry | | | |the home +------>| SIP |------->| SIP | |network |200 OK | Proxy |200 OK | Server | +-------+---+ +-----------+ +---+-------+ ^ | | ^ 200 OK| | 200 OK| | | | SIP | | SIP | | INVITE | | INVITE | v v | +--+------+ +---------+ | SIP | | SIP | | Client | | Client | +---------+ +---------+ bob@xyz.com joe@abc.com Figure 2: Mobile Node terminated SIP Session Initiation Figure 2 provides an example scenario of a user that wishes to establish a SIP session with bob@xyz.com. The SIP client of joe@abc.com issues the INVITE message to its local SIP Server (abc.com SIP Server). If the Serving SIP Proxy in the home network of bob@xyz.com is not known, the SIP Server SHOULD attempt to resolve the Home entry SIP Proxy within the home network, perhaps using a mechanism such as DNS. The INVITE method is forwarded to the Home entry SIP Proxy. Upon receipt of the SIP INVITE, the Home entry SIP Proxy MAY send an authorization request to the AAAH, in order to determine whether the session can be established and to find out which of the Serving SIP Proxy in the home network is assigned to the SIP Client. At that point, the Home entry SIP Proxy will forward the request directly to the Serving SIP Proxy in the home network (Figure 2). Upon receipt of the SIP INVITE method, the Serving SIP Proxy in the home network MAY send an authorization request to the AAAH, in order Calhoun et al. expires September 2002 [Page 10]
INTERNET DRAFT Feb 2002 to determine whether the session can be established. The authorization check by the AAAH MAY include other policy decisions, such as time of day, origination point of the session, etc. A successful response from the AAAH will result in the forwarding of the SIP INVITE method to the SIP Client. A response that includes an error would cause the Serving SIP Proxy in the home network to return an error back to the initiating SIP Server. 2.3.2 Invitation originating from the mobile node Home Network +----------+ +-------+ +----------+ | xyz.com | |xyz.com| | Naming | DSI |<->| AAAH | | Server | | Database | | server| | (e.g.DNS)| +----------+ +-------+ +----------+ ^ ^ ^ | | | +-----------+ | |abc.com? | | | v v v +-----------+INVITE +-----------+INVITE +-----------+ | Home +------->|Serving SIP+------>| abc.com | | entry | | Proxy in | | | | SIP |<-------+ the home |<------+ SIP | | Proxy |200 OK | network |200 OK | Server | +---+-------+ +-----------+ +------+----+ | ^ ^ | | | 200 OK| |SIP 200 OK| |SIP | |INVITE | |INVITE | | v | | v +------+--+ +-+-------+ | SIP | | SIP | | Client | | Client | +---------+ +---------+ bob@xyz.com joe@abc.com Figure 3: Mobile node initiated SIP Session Initiation Figure 3 provides an example of a user, bob@xyz.com, that wishes to establish a SIP session with joe@abc.com. The SIP Client of bob@xyz.com sends the SIP INVITE, either to his Home entry SIP Proxy, or directly to the Serving SIP Proxy in the home network, if this is known. If the Home entry SIP Proxy receives the SIP INVITE, it will after a location lookup in the DSI database, proxy it to the Serving SIP Proxy in the home network. Calhoun et al. expires September 2002 [Page 11]
INTERNET DRAFT Feb 2002 Upon receipt of the SIP INVITE method, the Serving SIP Proxy in the home network MAY send an authorization request to the AAAH, in order to determine whether the session can be established. The authorization check by the AAAH MAY include other policy decisions, such as time of day, origination point of the session, etc. A successful response from the AAAH will result in the forwarding of the SIP INVITE method to the SIP Client. A response that includes an error would cause the Serving SIP Proxy in the home network to return an error back to the initiating SIP Client. The authorization MAY be performed in the Serving SIP Proxy in the home network if the AAAH has provided the required information to the Serving SIP Proxy in the home network in the registration. The Serving SIP Proxy in the home network will, after this, use ordinary SIP proxying mechanisms to proxy the SIP INVITE to the SIP server serving joe@abc.com, which will proxy the message to the SIP Client of joe@abc.com. SIP 200 OK messages traverse back along the same path. 2.3.3 Session accounting During the SIP session establishment, the SIP server MAY initiate an accounting session towards the Accounting server in the home or visited network. SIP servers MAY generate several accounting records during the SIP session. At the end of the SIP session, a final accounting record should be issued that includes a summary of the SIP session. The accounting records should include accounting information that is necessary for billing and inter-network settlement purpose. Accounting information such as user identities (called and calling party Ids), SIP call Id, used media types, request-URI, QoS parameters (requested/negotiated quality of service), accounting correlation Id, and SIP session duration should be recorded. Any change during the SIP session that MAY affect the charge of SIP session (e.g. change of media type, additional service requested, call redirection) should be reflected in an accounting record. For example during session forwarding, the initial calling party (A) MAY incur the charges from A to B while the forwarding party MAY incur charges due to the 'forwarded' session. Also, if the called party requests additional media components with regard to the initial request from calling party then the called party MAY be charged for these additional components. Parameters for accounting generation SHOULD be configurable in the Calhoun et al. expires September 2002 [Page 12]
INTERNET DRAFT Feb 2002 SIP servers, or alternatively, the AAA server MAY indicate interim accounting information to the SIP server, which advises the SIP server when to generate the interim accounting records and if a cumulative or non-cumulative accounting model MUST be used. It should be noted that the traditional telco world currently makes use of, and prefers, non-cumulative accounting information. If SIP extensions (e.g. instant messaging, presence service) are used, some of the request or response messages in these extensions MAY trigger generation of accounting information. For example, a SIP SUBSCRIBE MAY trigger generation of a one-time event accounting record, session based instant messaging MAY trigger generation of accounting session and SIP INFO methods MAY trigger generation of an interim accounting message. Accounting data related to bearer payload (e.g. number of transmitted packets, used bandwidth) is assumed to be handled by other mechanisms than SIP and is not included in these requirements. However a unique accounting correlation Id MAY exist, which correlates the SIP session with specific bearer(s)in the access network. If the unique correlation Id exist, it MUST be included in all accounting records to be able to correlate the accounting information from SIP session to used bearer in the access network. 3.0 Requirements From the previous section, we can extract the following requirements for SIP-AAA interworking: 1. A basic requirement for Service Providers is to be able to integrate different networks for more efficient operations. IETF AAA efforts support this idea by striving for a single AAA architecture and protocol set. Whether access is supported by PPP, Mobile-IP, MEGACO or SIP, a common architecture and protocol set SHOULD be used. 2. The AAAH MAY authenticate a user based on the corresponding SIP REGISTER method. 3. The AAAH MAY authenticate a user session (the end result of a successful SIP INVITE method), implementing whatever policy it wishes, such as taking into account time of day, distance, etc. 4. The AAA infrastructure MUST be able to distribute (push or pull) subscriber/service/security profiles to the relevant SIP servers, based on policies Calhoun et al. expires September 2002 [Page 13]
INTERNET DRAFT Feb 2002 5. The AAAH MUST be able to update the entry for the assigned SIP server for the user performing SIP registration. 6. The AAAH MUST be able to provide the assigned server of the user to the SIP entities requesting it. 7. The AAAH MUST be able to initiate de-registration of the user. 8. The AAA infrastructure or the Home entry SIP Proxy MUST be able to allocate a SIP server for a subscriber at registration time, based on policies, load distribution etc. 9. The scheme supported for the authentication between the SIP servers and the AAA infrastructure MUST be flexible enough to accommodate current authentication mechanisms, e.g. using Subscriber Identity Module (SIM) card, and possible future authentication mechanisms. 10. Ability for SIP Servers to provide the duration of a session, the parties involved, and other relevant information to the visited and home AAA servers as accounting information. 11. The AAA accounting messages MUST separate the "session duration time" information from those generated via additional services (e.g. 3-way calling, etc.) 12. There MUST be support for accounting transfers where the information contained in the accounting data has a direct bearing on the establishment, progression and termination of a session. 13. There MUST be support for accounting transfers where the information contained in the accounting data does NOT have a direct bearing on the establishment, progression and termination of a session. 14. SIP servers MUST be able to provide relevant accounting information for billing and inter-network settlement purpose to home and visited AAA servers. Both one time event accounting records and session based (START, INTERIM, STOP records) accounting MUST be supported. 15. Any change during the SIP session that affects the charge of SIP session MUST be reflected in accounting messages. Calhoun et al. expires September 2002 [Page 14]
INTERNET DRAFT Feb 2002 16. The AAA accounting protocol MUST support accounting per media component (e.g. voice, video). The AAA accounting Protocol MUST enable different parties to be charged per media component. 17. Both cumulative and non-cumulative accounting model MUST be supported. 18. Parameters for accounting generation must either be configurable in the SIP servers or communicated by the AAA servers. 19. If possible the accounting for SIP session MUST be correlated to the bearer in the access network. 4.0 Security Considerations It+ is assumed that integrating AAA and IP Telephony/Multimedia will not introduce any new security risks. Therefore, the AAA data MUST be secured and obscured when transiting the network, the endpoints MUST be authenticated before data is sent, and the endpoints MAY be authorized to access certain types of AAA data. 5.0 References [1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Ses¡ sion Initiation Protocol". RFC 2543, March 1999. [2] Aboba et al, "Network Access AAA Evaluation Criteria". RFC 2989, November 2000. [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev¡ els", BCP 14, RFC 2119, March 1997. [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho¡ rization, and Accounting Requirements". RFC 2977, October 2000. [5] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Pro¡ tocol, Version 2", RFC 2165, June 1999. [6] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 1999. [7] H. Schulzrinne, L. Slutsman, I. Faynberg, H. Lu, "Interworking between SIP and INAP". draft-schulzrinne-sin-00.txt, IETF Work in Calhoun et al. expires September 2002 [Page 15]
INTERNET DRAFT Feb 2002 Progress, July 2000. [8] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC 1409, November 1998. 6.0 Acknowledgements The authors would like to thank the participants of the 3GPP and 3GPP2 working groups for their valuable feedback, and to Harri Hakala for very useful proposed text. 7.0 Authors' Addresses Questions about this memo can be directed to: Henrik Basilier Ericsson Inc. 2100 Shattuck Ave. Berkeley, Califonia, 94704 USA Phone: +1 858-361-4314 Fax: +1 510-666-3999 E-mail: henrik.basilier@ericsson.com Pat R. Calhoun Black Storm Networks 250 Cambridge Avenue Suite 200 Palo Alto, California, 94306 USA Phone: +1 650-617-2932 Fax: +1 720-293-7501 E-mail: pcalhoun@diameter.org Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803 U.S.A. E-mail: matt@ipverse.com Calhoun et al. expires September 2002 [Page 16]
INTERNET DRAFT Feb 2002 Tony Johansson Ericsson Inc. 2100 Shattuck Ave. Berkeley, Califonia, 94704 USA Phone: +1 510-305-6108 Fax: +1 510-666-3999 E-mail: tony.johansson@ericsson.com James Kempf Network and Security Research Center, Sun Laboratories Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: +1 650-786-5890 Fax: +1 650-786-6445 E-mail: james.kempf@eng.sun.com Jaakko Rajaniemi Nokia Networks P.O. Box 301 00045 Nokia Group Finland Phone: +358 50 3391387 Fax: +358 9 51130163 E-mail: jaakko.rajaniemi@nokia.com Calhoun et al. expires September 2002 [Page 17]
INTERNET DRAFT Feb 2002 8.0 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 docu¡ ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop¡ ing 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 lim¡ ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS¡ CLAIMS 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. Calhoun et al. expires September 2002 [Page 18]