Internet Engineering Task Force Stefano Faccin INTERNET-DRAFT Franck Le draft-zheng-diameter-pma-00.txt Srinivas Sreemanthula Haihong Zheng Nokia Research Center Profile Management Framework and Diameter Profile Management Application 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. Abstract This Internet draft introduces the concepts and motivations for an inter-domain user profile management framework, and shows that the combination of Diameter and the existing policy framework is well- suited for this purpose. The draft defines a new Diameter Profile Management Application (PMA) to support the inter-domain user profile management. The new Diameter PMA application specifies how to transfer and manage a user profile from its home network into the foreign network that the user is currently visiting. Combined with the inter-domain capability of the Diameter base protocol [1], the PMA application enables a network to enforce policies for a roaming user based not only on the local network policies but also the Faccin, Le, Sreemanthula, Zheng [Page i] INTERNET-DRAFT Diameter PMA November 2001 policies defined by the user home network and contained in the user profile. Faccin, Le, Sreemanthula, Zheng [Page ii] INTERNET-DRAFT Diameter PMA November 2001 1. Introduction IETF policy framework working group defined a framework for intra- domain policy definition and administration for a heterogeneous set of policy decision and enforcement points. However, as mobility and roaming are brought into the discussion by the work done in groups such as Mobile IP, inter-domain policy control becomes a relevant issue and should be considered in an appropriate policy framework. Among various issues, inter-domain policy control needs to allow enforcement of policies as a combination of the roaming user-specific policies defined by the home network and the local network policies. This draft defines a inter-domain policy framework and proposes its realization through the AAA infrastructure. Among other objectives, the draft aims at utilizing the existing protocols as much as possible, and identifies the interfaces for which the existing protocol cannot provide a workable or a scalable solution. Furthermore, this draft defines a new Diameter Application - the Diameter Profile Management Application (PMA), to be used on the aforementioned interfaces. 2. Terminology o User Profile: It is the set of user-specific policies defined by the user home network. The User Profile can contain policies regarding QoS (e.g. what QoS the user is entitled to request and in what situations), security (e.g. static security associations that the user shares with network entities, policies regarding when and how the user has to be authenticated), etc. o Downloaded User Profile: It is the profile that is downloaded into the visited network. It is a subset of the User Profile. The User Profile may contain more information that the home network may not want to share with visited networks (e.g. long term SAs the user shares with the home network). 3. Requirements Language In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [8]. Faccin, Le, Sreemanthula, Zheng [Page 1] INTERNET-DRAFT Diameter PMA November 2001 4. Background The IETF policy WG defines a framework for intra-domain policy definition and administration for a heterogeneous set of Policy Decision and Enforcement Points. The "intra-domain" refers to policy components that are all under the same administrative control. The major protocols used in this intra-domain policy framework include COPS[4][5] and LDAP[6]. Roaming imposes a number of new requirements on inter-domain policy control. It should be possible to restrict a mobile user in usage of the network resources by the policy rules defined by the foreign network and also the home network. The user's home network operator may regulate the user's access to a foreign network resources based on the agreement with the user, usually at the time of subscription. Based on their subscription profile, certain users may not be allowed to initiate certain sessions under certain circumstances (e.g., application type, day of week, time of day, location, etc.). It would be necessary for home network to ensure that these subscription conditions are enforced as per the agreement, no matter where the user is roaming. In addition, the home network may also wish to use a different set of user specific policies (i.e., profile parameters) for this particular user based on the roaming relation with the foreign network where the user is visiting. When the user is roaming in a foreign network, it is also in the interest of the foreign network to enforce its own network policies in certain ways. For example, the user's home operator may allow the user to reserve resources for video conferencing sessions, while the foreign operator may not want to allow such sessions at busy times, especially in wireless environments where the foreign network would not want to deplete the expensive radio resources for its own subscribers. Therefore, the final set of network policies should take into account both the home and network policy definitions. The foreign network policy control utilizes the new set of policy rules during the policy evaluation and enforcement to provide the network resources for the roaming users. Based on the reasons above, an inter-domain policy framework that allows user specific policies defined in the user profile to be enforced in a foreign network that the user is visiting is required. More specifically, a mechanism of retrieving user specific policies defined in user profile from the user home network to the network the user is visiting is needed. The existing protocols used in intra- domain policy framework, such as COPS and LDAP cannot satisfy such requirement. Faccin, Le, Sreemanthula, Zheng [Page 2] INTERNET-DRAFT Diameter PMA November 2001 COPS specifies a simple client-server protocol that can be used to exchange information between a policy server (PDP - Policy Decision Point) and its clients (PEPs - Policy Enforcement Points). The client-server model used in COPS requires PDPs and PEPs to know the identity such as the hostname or the IP address of each other. This can be easily implemented by static configuration or dynamic service discovery of the policy servers in a single domain network, however it is not practical in the inter-domain case. This is because it is not a scalable solution to let all the PEPs in the foreign network know a PDP in the home network of a roaming user. Therefore, it is not a scalable and practical solution to use COPS to perform user specific policy evaluation across different domains. Similar to COPS, LDAP, a directory access protocol, uses a simple client-server model. A LDAP client transmits a protocol request describing the operation to be performed to a LDAP server. The server is then responsible for performing the necessary operations in the directory, and returns a response containing any results or errors to the requesting client. It is difficult for a LDAP client in a foreign network where a user roams, to access a LDAP server in the user's home network, because LDAP clients and servers need to know each other's identity to set up communication and it is not a scalable solution to let every PDP (LDAP client) in the foreign network know a policy repository (LDAP server) in every possible foreign network that is the home network of a roaming user. Thus, it is also not scalable and practical to use LDAP to retrieve user specific policies from user home network to the network the user is visiting. Therefore, the existing protocols used in intra-domain policy framework cannot satisfy the requirement for the inter-domain case, and a new protocol is needed for this purpose. Based on these requirements, this draft defines an inter-domain policy framework and proposes its realization through a new Diameter application - Diameter Profile Management Application (PMA). As mentioned before, this framework aims at using the existing protocol as much as possible, and only defines the protocol that cannot be replaced by the existing protocols. 5. Framework and Protocol Overview This section describes the basic framework that support the inter- domain policy management. The interface used between the network entities defined in this framework are discussed, the need for the new protocol has been identified, and an overview of the new protocol has been made. Faccin, Le, Sreemanthula, Zheng [Page 3] INTERNET-DRAFT Diameter PMA November 2001 5.1. Framework The proposed policy management framework as shown in figure 1 is an extension of the existing policy framework. It brings the inter- domain profile management into consideration. A Profile Repository (PR) in the home network is assumed, which provides the storage for all the User Profiles for the users who are subscribed to its network. The PR could simply be a database or a directory, which is very similar to the policy repository defined in the IETF policy framework. When a user is in its home network, the user may be regulated by both local network policy rules stored in the policy repository as well as user specific policy rules defined by the User Profile stored in the profile repository. Policies rules are retrieved by Policy Decision Point (PDP) from policy and profile repositories and are evaluated by the PDP. When a user roams into a foreign network, the profile for the user is downloaded from the home network to the network it is visiting and is evaluated locally in the foreign network. +---------+ | +---------+ | Profile |----+-------------| Profile | | Manager | | | Manager | +---------+ | +---------+ | | | | LDAP | | LDAP | | | +------------+ | +------------+ LDAP | Profile | | LDAP | Profile | ------| Repository | | -------| Repository | | +------------+ | | +------------+ +-----+ COPS +-----+ | +-----+ | PEP |------| PDP | | | PDP | +-----+ +-----+ | +-----+ | LDAP +------------+ | | LDAP +------------+ ------| Policy | | --------| Policy | | Repository | | | Repository | +------------+ | +------------+ | visited network | home network Figure 1 Overall Framework for Inter-domain Policy Management The user profile downloaded to the foreign network, termed as downloaded user profile, contains the policy rules for a roaming user as defined in the home network. However, these rules may contain only Faccin, Le, Sreemanthula, Zheng [Page 4] INTERNET-DRAFT Diameter PMA November 2001 partial profile information, based on the capabilities and the roaming relationship with the foreign network. The PDP in the foreign network can evaluate a policy request based on the policy rules defined in the downloaded user profile. The location where the profile is stored in the foreign network is out of the scope of this document and a Profile Repository (PR) is assumed, which may store the downloaded user profiles for all the roaming users who are visiting this network. The profile repository in the foreign network can also simply be a database or directory, which is similar to the policy repository. The network entity that has the access to the profile repository for storage and retrieval of the user profiles and participate in profile downloading is termed as Profile Manager (PM). Upon certain explicit request or implicit triggering, the profile manager in the home network (PMh) retrieves a profile from the profile repository in the home network (PRh) and transmits it to the profile manager in the foreign network (PMf), who will then configure the profile into profile repository in the foreign network (PRf). The interface between profile manager and profile repository could be based on LDAP. Note that the PMh only retrieves a user profile from the PRh and transmits it to the foreign network, while the PMf only configures the profile into the PRf. They are not involved in the profile evaluation or policy decision. The policy rules defined in the user profile are evaluated by a PDP in the foreign network upon receiving a policy checking request sent from a Policy Enforcement Point (PEP) or another PDP. The interface used between these two entities could be COPS. The PDP that receives the policy checking request first decides if the user profile rules need to be enforced. If they do, the PDP retrieves the profile from the PRf and uses the rules to evaluate the request. The PDP may cache the profile for a certain period so that it can be used directly when the next similar request arrives. The interface between PDP and profile repository could be LDAP. During the caching period, if there is any change in the profile such as modification or removal, the profile repository needs to update the PDP with the change using LCUP [7]. The only interface that is not defined in the proposed framework is the interface between the profile managers in the foreign and home networks. Diameter is suggested for this interface, and Diameter Profile Management application is defined in this draft. Faccin, Le, Sreemanthula, Zheng [Page 5] INTERNET-DRAFT Diameter PMA November 2001 5.2. Issues With the proposed inter-domain policy framework, the following additional issues have been considered when designing the PMA. o Security Issue: When the home domain profile manager receives a request or a trigger to download the profile for a particular user into a foreign domain, it needs to verify that 1) the user has already been authenticated, and 2) the foreign network where the profile will be downloaded is the network, with which the user is currently registered, and also authorized. This basically implies that certain connection is needed between the user registration/authentication and profile downloading procedures. o Synchronization Issue: After the profile is downloaded into a foreign network, if there is any change in the user profile in the home network, the corresponding copy of the profile in the foreign network needs to be updated. The update request comes from the profile manager in the home network and is executed by the profile manager in the foreign network by configuring the new profile into the profile repository in the foreign network. o Mobility Issue: When a user roams out of a foreign network, the profile for the user in the foreign network must be removed. The removal could be triggered by a session termination request sent from the profile manager in the home network. Other options such as predefined timer are not excluded. The triggering is out of the scope of this document. 5.3. Protocol Analysis As mentioned before, the only interface that is not defined in the proposed framework is the interface between profile managers in the home and foreign networks. As discussed in section 4, the existing protocols including COPS and LDAP cannot efficiently support the inter-domain policy control. Instead, Diameter is the only protocol defined in IETF that has the capability and scalability to satisfy the inter-domain requirement. The Authentication Authorization and Accounting (AAA) infrastructure has been introduced by IETF, among other purposes, in order to support inter-domain authentication and authorization. As the AAA protocol, Diameter is the best and the only candidate to be used over the interface between PMs in the home and foreign networks. The Faccin, Le, Sreemanthula, Zheng [Page 6] INTERNET-DRAFT Diameter PMA November 2001 reasons are listed as follow. o AAA infrastructure enables an AAA node in the foreign network to communicate with AAA servers in the home network (AAAh) without knowing its hostname or IP address. All the intermediate AAA servers or proxies between the visited and home network can route the AAA message based on the destination realm. Such AAA inter- domain routing capability enables AAA node in the foreign domain to locate AAAh just based on the realm of user NAI, while COPS and LDAP protocols lack thereof. Such feature of AAA can enable the profile manager in the foreign network to easily send message to the profile manager in the home network without knowing its hostname or IP address. o As currently defined in IETF, user registration in most access protocols (e.g., Mobile IP v4, Mobile IPv6 and NASREQ) relies on AAA infrastructure to authenticate and authorize a user. Since authentication and authorization should be linked with profile downloading procedure due to security reasons as described in section 5.2, AAA should at least be involved to verify that the foreign network towards which the profile is downloaded is the foreign network that the user is registered with. o The user profile should be downloaded at the time of user registration. Therefore, the triggering to download the profile to the foreign network should be linked with registration process that is tied with AAA. Based on the reasons above, Diameter is selected to support profile downloading functions and used on the interface between PMf and PMh. Besides other functionality, a AAA server in the home network (AAAh) also acts as the PMh and a AAA node in the foreign network acts as the PMf. This draft defines a new Diameter application - PMA, which supports the inter-domain profile management. 5.4. Protocol Overview The Diameter PMA application enables profile management between different domains. With PMA application, a Diameter node in the network that a user is visiting can request the user's home network to download the user profile using a Profile-Downloading-Request (PDR) message. The home Diameter server that receives the PDR message replies with a Profile-Dowloading-Answer (PDA) message either with Faccin, Le, Sreemanthula, Zheng [Page 7] INTERNET-DRAFT Diameter PMA November 2001 the downloaded user profile or with the error indication. The home Diameter server can update the profile that was downloaded into the visited network before by sending a Profile-Update-Request (PUR) message with the updated profile. The Diameter node receiving the PUR message sends the response using the Profile-Update-Answer message after performing the profile update. If the visited or the home network wishes to remove the downloaded profile, they can terminate the session by sending STR or ASR messages, which triggers the Diameter node in the visited network remove the profile as well as the related session state. The details of these new command codes as well as the new AVP are described in section 6 and 7. The usage scenarios of these command codes are illustrated in section 8. 6. Command Codes This section defines the command code values that MUST be supported by all Diameter specifications that conform to the profile management application. The following command codes are defined in this section. +------------------------------+-------------+---------+-----------+ | Command Name | Abbreviation| Code | Reference | +------------------------------+-------------+---------+-----------+ | Profile-Downloading-Request | PDR | TBD | 6.1 | +------------------------------+-------------+---------+-----------+ | Profile-Downloading -Answer | PDA | TBD | 6.2 | +------------------------------+-------------+---------+-----------+ | Profile-Update-Request | PUR | TBD | 6.3 | +------------------------------+-------------+---------+-----------+ | Profile-Update-Answer | PUA | TBD | 6.4 | +------------------------------+-------------+---------+-----------+ | Session-Termination-Request | STR | 275 | 6.5 | +------------------------------+-------------+---------+-----------+ | Session-Termination-Answer | STA | 275 | 6.5 | +------------------------------+-------------+---------+-----------+ | Abort-Session- -Request | ASR | 274 | 6.6 | +------------------------------+-------------+---------+-----------+ | Abort-Session- -Answer | ASA | 274 | 6.6 | +------------------------------+-------------+---------+-----------+ 6.1. Policy-Downloading-Request (PDR) Command The Profile Downloading Request (PDR) command, indicated by the Command-Code field set to TBD and the 'R' bit set in the Command Flags field, is sent by a Diameter node to a Diameter server to Faccin, Le, Sreemanthula, Zheng [Page 8] INTERNET-DRAFT Diameter PMA November 2001 request for profile information for a given user. The User-Name AVP specifies the user for which the profile information is being requested. The optional Profile-Id AVP contains the type of the profile that the visited network is requesting to download. For example, a user may have different profiles when being served by different types of access network, such as WLAN and CDMA2K radio access network. If the Profile-Id AVP is not present, the default user profile is requested. The other AVPs are used according to the Diameter base protocol AVP definitions. Message format: ::= < Diameter Header, TBD, REQ, PXY > < Session-Id > { Auth-Application-Id } { User-Name } { Origin-Host } { Origin-Realm } { Destination-Realm } [ Destination-Host ] [ Origin-State-Id ] [ Profile-Id ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2. Profile-Downloading-Answer (PDA) Command The Policy Downloading Answer (PDA) command, indicated by the Command-Code field set to TBD and the 'R' bit cleared in the Command Flags field, is sent by a Diameter server in response to a PDR. If the grouped User-Profile AVP is present, it carries the applicable profile for the user. The lifetime of the downloaded user profile is indicated in the Authorization-Life-Time AVP. The use of User-Profile AVP is optional, since the home network may chose not to provide the profile information for the user. If this happens, the Result-Code AVP with the value of DIAMETER_ERROR_REQUEST_REJECT. However, if the result code indicates DIAMETER_PROFILE_NO_RESTRICTION, this implies that the given user is not restricted by any profile policies. If the server doesn't recognize the given user as indicated in the User-Name AVP, it MUST return a Result-Code using DIAMETER_USER_UNKNOWN error code. If the serven doesn't find the profile for the specific user, it MUST return Faccin, Le, Sreemanthula, Zheng [Page 9] INTERNET-DRAFT Diameter PMA November 2001 a Result-Code using DIAMETER_ERROR_NO_PROFILE. If the user has not be authenticated or the authenticated failed during registration period, the Result-Code with the value of DIAMETER_ERROR_USER_NOT_AUTHENTICATED is sent. If the network where the PDR originated is not the network that the user is roaming to, the Result-Code with the value of DIAMETER_ERROR_UNKNOWN_NETWORK is sent in PDA. All the other errors should be reported in the Result- Code AVP using the error code defined in the Diameter base protocol. Message format: ::= < Diameter Header: TBD, PXY > < Session-Id > { Auth-Application-Id } { Authorization-LifeTime } { Auth-Grace-Period } { Auth-Session-State } { Origin-Host } { Origin-Realm } { User-Name } { Result-Code } [ User-Profile ] [ Error-Message ] [ Error-Reporting-Host ] [ Session-Timeout ] [ Origin-State-Id ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.3. Profile-Update-Request (PUR) Command The Profile Update Request (PUR) command, indicated by the Command- Code field set to TBD and the 'R' bit set in the Command Flags field, is sent from a Diameter server to a Diameter node that sends the PDR message, requesting the Diameter node to re-configure the downloaded user profile carried in the User-Profile AVP into the profile repository in the foreign network. The User-Profile AVP is mandatory and carries the applicable profile for the user whose identity is carried in the User-Name AVP. Note that it is possible to send an empty rule-set in the User-Profile AVP, which implies that the given user is unrestricted by any profile rules. The lifetime of the downloaded user profile is indicated in the Authorization-Life-Time AVP. The Session-Id used in this message should be the same as the one assigned for PDR message. This command is used for updating profile in the foreign network if any profile rule is changed in the Faccin, Le, Sreemanthula, Zheng [Page 10] INTERNET-DRAFT Diameter PMA November 2001 home domain. Other usage of this command could be pushing profile from home to the foreign network without receiving PDR message. As an example, if the home and the foreign networks have roaming agreement that profile needs to pushed from home to the foreign network right after the registration request is approved, the PUR message is sent after a user registration request succeeds. Message format: ::= < Diameter Header: TBD, REQ, PXY > < Session-Id > { Auth-Application-Id } { Authorization-LifeTime } { Auth-Grace-Period } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } { User-Name } { User-Profile } [ Profile-Id ] [ Session-Timeout ] [ Destination-Host ] [ Origin-State-Id ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.4. Profile-Update-Answer (PUA) Command The Profile Update Answer (PUA) command, indicated by the Command- Code field set to TBD and the 'R' bit cleared in the Command Flags field, is sent in response to a PUR to indicate the processing result of the PUR. The Result-Code AVP is used to indicate if PUR was successfully processed or an error occurred. If the update performed by the Diameter node in the foreign netowrk failed, the Result-Code AVP should be sent with the value of DIAMETER_ERROR_UPDATE_FAILURE. Other error codes to be used in PUA are defined in the Diameter base protocol. Message format: Faccin, Le, Sreemanthula, Zheng [Page 11] INTERNET-DRAFT Diameter PMA November 2001 ::= < Diameter Header: TBD, PXY > < Session-Id AVP > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { User-Name } { Result-Code } [ Profile-Id ] [ Error-Message ] [ Error-Reporting-Host ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.5. Session Termination The diameter node that has previously downloaded the user profile from the user's home network can initiate a STR message to the diameter server to indicate the removal of the user profile. The diameter server MUST clean up all the state information related to this event and respond with a STA. The user NAI is carried in the User-Name AVP. If the Diameter server that receives the request doesn't recognize the given user as indicated in User-Name AVP, it must return an error. The message formats for the STR and STA are provided in the Diameter Base Protocol [1]. 6.6. Aborting a Session The home diameter server can send an ASR to the diameter node in the foreign network, which sends the PDR or PUA before, to terminate the profile related session for a particular user. The diameter client that received the ASR must delete the profile for the user and return the status in the ASA. If there is no corresponding profile in the profile repository for the given user, the DIAMETER_ERROR_NO_PROFILE error code needs to be included in the Result-Code AVP. All the other errors should be reported in the Result-Code AVP using the error code defined in the Diameter base protocol. The message formats for the ASR and ASA are provided in the Diameter Base Protocol [1]. Faccin, Le, Sreemanthula, Zheng [Page 12] INTERNET-DRAFT Diameter PMA November 2001 6.7. Advertising Application Support Diameter nodes conforming to this specification MAY advertise support by including the value of TBD in the Auth-Application-Id AVP of the Capabilities-Exchange-Request and Capability-Exchange-Answer command [1]. 7. Supporting AVPs The two new AVPs introduced in this specification are the Profile-Id AVP and the User-Profile AVP. The following table shows the usage of the new AVPs as well as the base AVPs used for a specific purpose of the Diameter PMA. Attribute Name Section Purpose ---------------------------------------------------------------------- User-Name - The user for which the profile is used Authorization - The lifetime for which the profile is valid -Lifetime User-Profile 7.1 Defines the user profile parameters Profile-Id 7.2 Defines profile identifier The following table shows the AVP flag information. | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Data Type |MUST| MAY | NOT| NOT|Encr| --------------------------------+----+-----+----+-----|----| User-Profile TBD Grouped | M | P | | V | Y | Profile-Id TBD Unsigned32 | M | P | | V | Y | 7.1. User-Profile AVP The User-Profile AVP is defined as a grouped AVP, but the exact format of the AVP depends on the content of the profile. Different service providers may have different definition of user profile. Therefore, in order to enable different service profile to understand the profile of each other, the content of profile needs to be either standardized or agreed between different service providers. The Faccin, Le, Sreemanthula, Zheng [Page 13] INTERNET-DRAFT Diameter PMA November 2001 format of this AVP will be defined in the future version. 7.2. Profile-Id AVP The Profile-Id AVP is a Unsigned32 type that contains the information to indicate the type of the profile that the visited network requests for. It is assumed that the home network may maintain several profiles that may be applicable to specific access networks for the same user. The visited network may request only the relevant profile from the home network by the use of this AVP. It is also possible that the use of this AVP could extended for other purposes. However, the values of this AVP must be standardized (TBD). 7.3. Result-Code AVP The Result-Code AVP is used to indicate whether a particular request was completed successfully or whether an error happened. This section defines the new Result-Code values that MUST be supported by all Diameter implementations that conform to this specification. DIAMETER_ERROR_NO_PROFILE 7001 A home diameter server uses this result code when processing PDR has been failed due to non-existing profile for the requesting user. It is also used by a diameter node that receives an ASR to indicates error if no valid profile exist in the profile repository in the foreign network. DIAMETER_ERROR_REQUEST_REJECT 7002 A home diameter server uses this result code that rejects the PDR or PUR request due to network policy. DIAMETER_ERROR_UPDATE_FAILURE 7003 A visited network diameter server uses this result code when processing PUR and updating the received profile into the profile repository in the foreign network has failed. DIAMETER_ERROR_UNKNOWN_USER 7004 Faccin, Le, Sreemanthula, Zheng [Page 14] INTERNET-DRAFT Diameter PMA November 2001 A home diameter server uses this result code when processing PDR to indicate that the user name is not recognized in the network. DIAMETER_ERROR_USER_NOT_AUTHENTICATED 7005 A home diameter server uses this result code when processing PDR to indicate that the user is not authenticated within a certain time. DIAMETER_ERROR_UNKNOWN_NETWORK 7006 A home diameter server uses this result code when processing PDR that the requesting network is not allowed to download the profile. DIAMETER_PROFILE_NO_RESTRICTION 7007 A home diameter server uses this result code when PDA is created. It indicates that the profile is not provided with PDA but the user has no specific policy restrictions. 8. Usage Scenarios This section illustrates some usage scenarios of how to use the Diameter PMA. These usage scenarios include user profile downloading during the user registration period, profile update during a session, and profile removal at the end of a session. 8.1. User Profile Downloading A User Profile can be downloaded from its home network to a network that the user is currently visiting. Although profile management is a standalone application, it needs to interact with other diameter applications for the network access protocols such as Mobile IPv4, Mobile IPv6 and NASREQ. In general, the profile downloading can be requested at the time of the user authentication and registration with the visited network. However, the home network may chose to respond to the profile downloading requests only after the user is registered and authenticated. After receiving the user profile, the diameter node (PMf) supporting the PMA in the visited network stores it in the profile repository that is accessible by other nodes in the visited network for profile evaluation use. The diameter node handling the profile in the visited network does not need to maintain Faccin, Le, Sreemanthula, Zheng [Page 15] INTERNET-DRAFT Diameter PMA November 2001 the state information for the user. 8.1.1. Triggering of Profile Downloading Request This draft does not intend to define a specific mechanism of triggering of profile management procedures. The following discussion uses mobile IPv4 Diameter application [2] only as an example to demonstrate how to use this new Diameter Profile Management application. However, other Diameter applications (e.g. Mobile IPv6 application [9], NASREQ application [10]) can also be used in association with the PMA. When used with Diameter Mobile IPv4 application, the triggering of sending a PDR message could be the reception of a registration request (e.g. AMR) from an access device or a registration answer (e.g., AMA) from the home network. The diameter client (e.g., Foreign Agent in Mobile IPv4 application) handling the registration requests for the MN may or may not be the PMf, i.e., the Diameter node that handles the profile management functions. However, when used with other applications, registration/authentication messages pertaining to that application can act as triggers. 8.1.2. Initiating Profile Downloading Request A PDR message is created, when the profile management application is activated due to any of the triggers described above. In this section, the profile management behavior for a specific trigger associated with the AMA message of Diameter Mobile-IP application is shown. Some AVP from the triggering message (e.g., AMA) is also used in creating the PDR message (e.g. User-Name AVP, Origin-Host AVP). An optional Profile-Id AVP is also created to indicate the type of the user profile required by the visited network. For instance, the Profile-Id may indicate the access network type (e.g. WLAN, CDMA-2K), so that the home network can only download user profile information relevant to that particular access network. Any diameter node in the visited network can initiate the PDR message. Two scenarios are discussed here. o In the first scenario, the diameter client (i.e., Foreign Agent) is the PMf, which directly sends a PDR request after receiving an AMA that indicates successful authentication and registration for the user. Faccin, Le, Sreemanthula, Zheng [Page 16] INTERNET-DRAFT Diameter PMA November 2001 o In the second scenario, the diameter gateway server in the visited network may route the diameter registration answer (AMA) through the diameter node that is capable of handling the profile management (i.e., PMf). It may also be possible to configure the diameter network routing so that at least one diameter node that is capable of Diameter PMA functions is in the route of AMA. Upon receiving a successful AMA, the PMf shall route the registration message towards the FA as per normal diameter routing, and at the same time it should initiate a PDR message towards the AAAh that sends the AMA message. The hostname of the AAAh is obtained from the Origin-Host in AMA message. 8.1.3. Processing Profile Downloading Request Upon receiving a PDR, if AAAh doesn't recognize the user name as a valid user in its network, it must respond with a Profile Downloading Answer (PDA) message with the result code set to DIAMETER_ERROR_UNKNOWN_USER. If the user name is valid, AAAh then checks if the user has been authenticated, which is performed after receiving the AMR message. If the user has already been authenticated, the AAAh retrieves the profile from the profile repository and sends it to the PMf in the User-Profile AVP using Profile Downloading Answer (PDA) message with the Result-Code set to success. If the authentication has not been performed or failed before, the AAAh sends a PDA indicating the failure by using DIAMETER_ERROR_USER_NOT_AUTHENTICATED in the Result-Code. For these purposes, AAAh should be able to verify if the user is authenticated either by being stateful or by querying some other node that maintains such state information. This information is used to allow the profile to be downloaded only for a user who is registered and authenticated. For the future use of profile update, the AAAh MUST also maintain other state information such as Origin-Host and Session-Id carried in the PDR message. In addition, while processing the PDR request, AAAh must verify that the request is originated from the same realm as where the user is roaming. This provides security protection from spurious requests from unknown nodes trying to request the user profile. Comparing the realm parts of the Origin-Host AVPs in PDR and AMR messages can easily do this. If there is no match in this information the home diameter server must send DIAMETER_ERROR_UNKNOWN_NETWORK in the Result-Code. The following figure shows the details of the profile downloading procedure with the second scenario described in section 8.1.2. When a user sends a registration request to the Foreign Agent (FA), FA sends an AMR message to the home network of the user. After processing the Faccin, Le, Sreemanthula, Zheng [Page 17] INTERNET-DRAFT Diameter PMA November 2001 AMR, the AAAh responds with an AMA back to the FA. The AMA message is routed through the PMA capable diameter node (PMf) after it enters the foreign network. When the AMA reaches the PMf, before routing the AMA to the FA, PMf also obtain the user name from the User-Name AVP and the address of the AAAh from the Origin-Host AVP in the AMA and sends a Profile Downloading Request (PDR) message to the AAAh to request to download the profile for the same user. Foreign Home MN Foreign Diameter Diameter Diameter Agent Agent(PMf) Server(AAAf) Server(AAAh) | Regist. | | | | | Request | | | | |---------->| 2. AMR | | | | |--------------->|------------->| 2.AMR | | | | |------------>| | | | | +-------------+ | | | | |Authenticate | | | | | +-------------+ | | | 3. AMA |<------------| | | |<-------------| | | | | 4'. PDR | | | | |------------->| 4'. PDR | | | 4. AMA | |------------>| | Regist. |<---------------| | 5'. PDA | | Ack | | |<------------| |<----------| | 5`. PDA | | | | |<-------------| | | | | | | Figure 2. Profile Downloading 8.1.4. Processing Profile Downloading Answer The AAAh sends a PDA message containing a User-Profile AVP that provides the user profile information to the PMf. After receiving the PDA with a user profile, PMf configures the profile into profile repository in the foreign network. The PMf does not save any information about the user or its profile. Faccin, Le, Sreemanthula, Zheng [Page 18] INTERNET-DRAFT Diameter PMA November 2001 8.2. User Profile Update The home network may want to update the existing user profile in a foreign network due to different types of reasons such as the profile lifetime is about to expire or there are changes to the user profile. As an example, while the user profile is being used in a visited network, the user or the home network may make changes to the user profile due to subscription changes or any other management functions. Whenever the change happens, based on state information established during the profile downloading phase and maintained for the user, the home diameter server can find out the foreign networks where the user profile is presently active, and then should update the profile in the foreign network by sending a PUR message with the new profile and new authorization lifetime. Upon receiving PUR, the diameter node handling the profile management application responds with a PUA message after successfully replacing the old profile with the new profile. The PUA message contains a result-code indicating the result of the operation. The home diameter server updates the state information based on the result- code value. If the result-code indicates that the operation failed, then it is up to the home diameter whether or not to terminate the session or send the update request again. The following figure shows the flows of profile updating procedure. Faccin, Le, Sreemanthula, Zheng [Page 19] INTERNET-DRAFT Diameter PMA November 2001 Foreign Foreign Home Diameter Diameter Diameter Agent(PMf) Server(AAAf) Server(AAAh) | | | | 1. PDR | | |------------->| 1.PDR | | |------------>| | | +-------------+ | | |Authenticate | | | +-------------+ | | 2. PDA | | |<------------| | 2 . PDA | | |<-------------| | | | | ~ ~ ~ ~ ~ ~ | | | | | 3. PUR | | 3. PUR |<------------| |<-------------| | | 4. PUA | | |------------->| 4. PUA | | |------------>| Figure 3. Profile Update 8.3. User Profile Removal The home diameter server must send a request to removal the profile when the authorization life time expires, when the user deregisters with the network or for other management reasons. Abort-Session- Request (ASR) with the user name is sent to the diameter node(s) that configured user profile into profile repository. The diameter node must initiate to remove the profile from the profile repository in the visited network and possibly perform other operations to invalidate the use of this user profile information in its network. The result is indicated in the Result-Code AVP in the ASA response. An indication to profile removal must be sent by the PMf in the foreign network to the home Diameter server to indicate that the user profile is not used anymore. The reasons for this event include, but are not limited to, expiration of the authorization lifetime or deregistration of the user. The diameter node in the visited network Faccin, Le, Sreemanthula, Zheng [Page 20] INTERNET-DRAFT Diameter PMA November 2001 must send an STR as specified in the Diameter base protocol [1] to the home diameter server. The home diameter server must clean up the related state information and other resources and respond with an ASA along with the appropriate result code. 9. Security Consideration The use of this new Diameter PMA application may require some interaction with the user authentication. As described in section 8.1, before downloading the user profile, the home network should not only make sure the user is authenticated but also verify that the requesting network is the network the user is currently visiting. Except for these requirements, this Diameter PMA Application does not introduce any new security threats. 10. References [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diameter Base Protocol", draft-ietf-aaa- diameter-08-alpha02.txt, IETF work in progress, November 2001. [2] P. Calhoun, C. Perkins, "Diameter Mobile IPv4 Application", draft-ietf-aaa-diameter-mobileip-08-alpha02.txt, IETF work in progress, November 2001. [3] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [4] D. Durham, J. Boyle, R. Cohen et al., "The COPS (Common Open Policy Service) Protocol", RFC 2753, January 2000. [5] K. Chan, J. Seligson, D. Durham et al., "COPS Usage for Policy Provisioning (COPS-PR), RFC 3084, March 2001. [6] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [7] R. Megginson, M. Smith, O. Natkovich et al., "LDAP Client Update Protocol", draft-ietf-ldup-lcup-01.txt, IETF work in progress, June 2001. Faccin, Le, Sreemanthula, Zheng [Page 21] INTERNET-DRAFT Diameter PMA November 2001 [8] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] S. Faccin, F. Le, B. Patil and C. Perkins, "Diameter Mobile IPv6 Application", draft-le-aaa-diameter-mobileipv6-00.txt, IETF work in progress, June 2002. [10] P. Calhoun, W. Bulley, A. Rubens, J. Haag and G. Zorn, "Diameter NASREQ Application", draft-ietf-aaa-diameter- nasreq-08.txt, IETF work in progress, November 2001. 11. Authors's Addresses Stefano Faccin Nokia Research Center 6000 Connection Drive Phone: +1 972 894 4994 Irving, Texas Fax: +1 972 894 4589 75039 Email: stefano.faccin@nokia.com Haihong Zheng Nokia Research Center 6000 Connection Drive Phone: +1 972 894 4232 Irving, Texas Fax: +1 972 894 4589 75039 Email: Haihong.Zheng@nokia.com Franck Le Nokia Research Center 6000 Connection Drive Phone: +1 972 374 1256 Irving, Texas Fax: +1 972 894 4589 75039 Email: Franck.Le@nokia.com Srinivas Sreemanthula Nokia Research Center 6000 Connection Drive Phone: +1 972 894 4356 Irving, Texas Fax: +1 972 894 4589 75039 Email: srinivas.sreemanthula@nokia.com Faccin, Le, Sreemanthula, Zheng [Page 22]