Internet Engineering Task Force T. Tsou, Ed. Internet-Draft Huawei Technologies Intended status: Informational July 13, 2009 Expires: January 14, 2010 Diameter Routing Problem Statement draft-tsou-dime-routing-problem-statement-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Tsou Expires January 14, 2010 [Page 1] Internet-Draft Diameter Routing Problem Statement July 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes use cases that suggest a requirement to be able to add constraints to the existing Diameter routing mechanisms so that subsequent messages in a session pass through specific proxies that were on the initial path that set up the session. Routing between these proxies may use the present Diameter rules. 1. Introduction In [RFC3588], routing of request messages from source to the destination is based solely on the routing decision made by each node along the path. This document presents two different cases where the basic Diameter routing behaviour is not sufficient to meet the requirements. It then provides a problem statement based on these two cases. The basic problem rtelates to stateful proxies and the need to revisit them in subsequent messaging relating to a given session. 2. Requirements Language This document contains no requirements language. 3. Use Cases 3.1. 3GPP Wireless LAN (WLAN) Access Architecture One example of a stateful proxy is in the 3GPP WLAN IP access architecture [TS23.234]. The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side. It enables a 3GPP subscriber to use a WLAN to access 3GPP services. WLAN AAA provides access to the WLAN to be authenticated and authorised through the 3GPP system. This access control can permit or deny a subscriber the access to the WLAN system and/or the interworking with the 3GPP system. There are two WLAN interworking reference models: Tsou Expires January 14, 2010 [Page 2] Internet-Draft Diameter Routing Problem Statement July 2009 1. In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging. 2. In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required. After a successful authentication, a Diameter session is established involving (at least) the following stateful entities: o The Diameter client in the WLAN AN, o a Diameter proxy (the 3GPP AAA proxy) in the selected visited mobile network, and o a Diameter server in the UE's home realm. The functions assigned to the 3GPP AAA proxy include: o reporting charging information to the offline charging system in the visited network; o enforcing policies based on roaming agreements; o service termination initiated by the visited network operator. These functions all require that state be maintained within the visited network. The 3GPP choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session. The network model with the client, the proxy and the server as described above is simplistic. Operators would usually deploy more than one proxy in the visited network and more than one server in the home network for better availability and load sharing. Relays are also used at the edges of these networks for topology hiding and load balancing. Thus a realistic network model would typically involve some stateless agents also in the session path. Tsou Expires January 14, 2010 [Page 3] Internet-Draft Diameter Routing Problem Statement July 2009 3.2. Key Management for the EAP Re-authentication Protocol (ERP) ERP provides a way to reduce the cost of reauthentication of a peer by deriving additional keys from the original authentication exchange. In the case where reauthentication is to be done in a different domain from the home domain, the process uses a Domain Specific Root Key (DSRK) which is cached with a domain server in that other domain. The server is associated with a Diameter proxy which is capable of ERP support. Suppose that the DSRK is cached with the Diameter proxy/domain server in the other domain at the time of the original authentication exchange. Then if there are multiple such Diameter proxy/domain server combinations in a given domain, the problem upon reauthentication is to locate the one that has the cached DSRK. If the authenticating client needs to reach the home domain, but should be authenticated en route, then the problem is one of being able to specify that the route should include the required Diameter proxy. If, on the other hand, the authentication process stands alone, so that the erstwhile Diameter proxy can be viewed as a Diameter server instead, then the problem becomes one of capturing the identity of that Diameter server during the initial authentication exchange. 4. Problem Statement This is the statement of the problem posed by the cases presented in Section 3. 1. Existing Diameter message routing behaviour: each host along the path makes its own independent routing decisions. 2. Undesirable behaviour in the existing method: routing of all messages for a given session through the selected proxy is not guaranteed if the network has multiple eligible proxies or if there are other Diameter entities between the client and the target proxy. 3. Desired behaviour: regardless of the intervening set of Diameter elements, all messages for a given session pass through the proxy initially selected. This is required for stateful proxies only. 5. Acknowledgements Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn provided the problem statement template used in Section 4. Tsou Expires January 14, 2010 [Page 4] Internet-Draft Diameter Routing Problem Statement July 2009 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations It is possible that there are security issues with the problems stated above, but they are not immediately evident. 8. References 8.1. Normative References [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 8.2. Informative References [TS23.234] 3GPP, "TS23.234v7.7.0, 3GPP system to Wireless Local Area Network (WLAN) interworking; System description", June 2008. Author's Address Tina Tsou (editor) Huawei Technologies Section F, Huawei Industrial Base Bantian Longgang, Shenzhen 518129 P.R. China Phone: +86 755 28972912 Email: tena@huawei.com Tsou Expires January 14, 2010 [Page 5]