One document matched: draft-tsou-dime-routing-problem-statement-01.txt

Differences from draft-tsou-dime-routing-problem-statement-00.txt

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]