[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-tsou-dime-realm-based-redirect) 00 01 02 03 04 05 RFC 7075

Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                            T. Taylor, Ed.
Updates: RFC 3588                                    Huawei Technologies
(if approved)                                              July 30, 2009
Intended status: Standards Track
Expires: January 31, 2010


                  Realm-Based Redirection In Diameter
                draft-ietf-dime-realm-based-redirect-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 31, 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
   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

   RFC 3588 allows a Diameter redirect agent to specify one or more



Tsou & Taylor           Expires January 31, 2010                [Page 1]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


   individual hosts to which a Diameter message may be redirected by an
   upstream Diameter node.  However, in some circumstances an operator
   may wish to redirect messages to an alternate domain without
   specifying individual hosts.  This document specifies the means by
   which this can be achieved.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Realm-Based Redirection . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Behaviour of Diameter Nodes . . . . . . . . . . . . . . . . 3
       2.1.1.  Behaviour at the Redirect Agent . . . . . . . . . . . . 3
       2.1.2.  Behaviour of Other Diameter Nodes . . . . . . . . . . . 4
     2.2.  The Redirect-Realm and Redirect-Realm-Usage AVPs  . . . . . 4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6






























Tsou & Taylor           Expires January 31, 2010                [Page 2]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


1.  Introduction

   The usual redirect indication as described in Section 6.1.7 and
   Sections 6.12-6.14 of [RFC3588] returns one or more individual host
   names to the upstream Diameter node.  However, consider the case
   where an operator has offered a specific service but no longer wishes
   to do so.  The operator has arranged for an alternative domain to
   provide the service.  To aid in the transition to the new
   arrangement, the original operator maintains a redirect server to
   indicate the alternative destination to upstream nodes.  However, the
   original operator has no interest in configuring a list of hosts in
   the alternative operator's domain, and would prefer simply to provide
   redirect indications to the domain as a whole.

   Within this specification, the term "realm-based redirection" is used
   to refer to a mode of operation where the redirect indication
   specifies a realm and the upstream Diameter node reroutes the message
   to the realm rather than an individual host.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Realm-Based Redirection

   This section specifies an update to [RFC3588] to achieve realm-based
   routing.  The elements of this solution are:

   o  a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011);

   o  two new attribute-value pairs (AVPs), Redirect-Realm and Redirect-
      Realm-Usage; and

   o  associated behaviour at Diameter nodes implementing this
      specification.

2.1.  Behaviour of Diameter Nodes

2.1.1.  Behaviour at the Redirect Agent

   This specification modifies Section 2.7 of [RFC3588] to permit
   REDIRECT routing table entries to contain an alternative realm
   instead of individual home server identities.

   This specification modifies Section 6.1.7 of [RFC3588].  If the



Tsou & Taylor           Expires January 31, 2010                [Page 3]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


   realm-based routing table for a request contains a realm rather than
   one or more home server identities, the redirect agent MUST set the
   Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION rather than
   DIAMETER_REDIRECT_INDICATION.  Furthermore, the redirect agent MUST
   insert a Redirect-Realm AVP containing the realm from the routing
   table entry in its answer message instead of one or more Redirect-
   Host AVPs.  It SHOULD insert a Redirect-Realm-Usage AVP and Redirect-
   Max-Cache-Time AVP to indicate the scope and persistence of the
   redirection in upstream Diameter nodes' routing caches.  To prevent
   confusion at Diameter nodes receiving the answer message, the Result-
   Code AVP MUST include the Error-Reporting-Host AVP if the host
   setting the Result-Code AVP is different from the identity encoded in
   the Origin-Host AVP, in conformity with Section 7.1 of [RFC3588].
   All other aspects of Section 6.1.7 remain the same as for host-based
   redirection.

2.1.2.  Behaviour of Other Diameter Nodes

   A Diameter node conforming to this specification which receives an
   answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION
   SHOULD attempt to reroute the request to the indicated realm using
   normal discovery procedures to find an appropriate destination host.
   The receiving Diameter node SHOULD update its cache of routing
   entries according to the directions provided by the Redirect-Realm-
   Usage and Redirect-Max-Cache-Time AVPs, if present.

2.2.  The Redirect-Realm and Redirect-Realm-Usage AVPs

   The Redirect-Realm AVP (code TBD) is of type DiameterIdentity.  It
   specifies a realm to which a node receiving a redirect indication
   containing the result code value DIAMETER_REALM_REDIRECT_INDICATION
   and the Redirect-Realm AVP SHOULD route the original request.  The M
   and V flags for the Redirect-Realm AVP MUST NOT be set.

   The Redirect-Realm-Usage AVP (AVP Code TBD) is of type Enumerated.
   This AVP MAY be present in answer messages whose 'E' bit is set and
   the Result-Code AVP is set to DIAMETER_REALM_REDIRECT_INDICATION.
   When present, this AVP dictates how the routing entry resulting from
   the Redirect-Realm is to be used.  The following values are
   supported:

   DONT_CACHE  0

      The host specified in the Redirect-Realm AVP should not be cached.
      This is the default value.






Tsou & Taylor           Expires January 31, 2010                [Page 4]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


   ALL_SESSION  1

      All messages within the same session, as defined by the same value
      of the Session-ID AVP MAY be sent to a host in the realm specified
      in the Redirect-Realm AVP.

   ALL_REALM  2

      All messages destined for the realm requested MAY be sent to a
      host in the realm specified in the Redirect-Realm AVP.

   REALM_AND_APPLICATION  3

      All messages for the application requested to the realm specified
      MAY be sent to a host in the realm specified in the Redirect-Realm
      AVP.

   ALL_APPLICATION  4

      All messages for the application requested MAY be sent to a host
      in the realm specified in the Redirect-Host AVP.

   ALL_HOST  5

      All messages that would be sent to the host that generated the
      Redirect-Realm MAY be sent to a host in the realm specified in the
      Redirect- Realm AVP.

   ALL_USER  6

      All messages for the user requested MAY be sent to a host in the
      realm specified in the Redirect-Realm AVP.

   Section 6.14 of [RFC3588] is modified to permit the Redirect-Max-
   Cache-Time AVP to be used also to specify the persistence of cache
   entries created by the Redirect-Realm AVP.


3.  Security Considerations

   Because real-based redirection implies a change in business
   relationships, the node acting on the redirect indication SHOULD
   verify that the new realm is authorized to perform the requested
   service.  Similarly the originator of the request SHOULD perform an
   authorization check of the path as described in Section 2.10 of
   [RFC3588].





Tsou & Taylor           Expires January 31, 2010                [Page 5]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


4.  IANA Considerations

   This specification adds a new AVP code [286???]  Redirect-Realm in
   the AVP Code registry under Authentication, Authorization, and
   Accounting (AAA) Parameters.

   This specification allocates a new Result-Code value
   DIAMETER_REALM_REDIRECT_INDICATION (3011) in the Result-Code AVP
   Values (code 268) - Protocol Errors registry under Authentication,
   Authorization, and Accounting (AAA) Parameters.


5.  Acknowledgements

   Glen Zorn, Sebastien Decugis, and Wolfgang Steigerwald contributed
   comments that helped to shape this document.


6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.


Authors' Addresses

   Tina Tsou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: tena@huawei.com


   Tom Taylor (editor)
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa
   Canada

   Email: tom.taylor@rogers.com






Tsou & Taylor           Expires January 31, 2010                [Page 6]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/