Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7075.
Expired & archived
Authors Tina Tsou (Ting ZOU) , Tom Taylor
Last updated 2012-07-13 (Latest revision 2012-01-10)
Replaces draft-tsou-dime-realm-based-redirect
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7075 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-dime-realm-based-redirect-04
Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Updates: RFC 3588 (if approved)                           T. Taylor, Ed.
Intended status: Standards Track                     Huawei Technologies
Expires: July 14, 2012                                  January 11, 2012

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

Abstract

   RFC 3588 allows a Diameter redirect agent to specify one or more
   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 a mechanism by
   which this can be achieved.  New applications may incorporate this
   capability by reference to the present document.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 14, 2012.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Tsou & Taylor             Expires July 14, 2012                 [Page 1]
Internet-Draft     Realm-Based Redirection In Diameter      January 2012

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Support of Realm-Based Redirection Within Applications  . . . . 3
   3.  Realm-Based Redirection . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Behaviour of Diameter Nodes . . . . . . . . . . . . . . . . 4
       3.1.1.  Behaviour at the Redirect Agent . . . . . . . . . . . . 4
       3.1.2.  Behaviour of Other Diameter Nodes . . . . . . . . . . . 5
     3.2.  The Redirect-Realm AVP  . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6

Tsou & Taylor             Expires July 14, 2012                 [Page 2]
Internet-Draft     Realm-Based Redirection In Diameter      January 2012

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.  Support of Realm-Based Redirection Within Applications

   Because realm-based redirection is not part of base Diameter
   behaviour, support for realm-based redirection by the agent MUST be
   specified as part of particular applications.  In this way,
   Diameter's capability negotiation mechanism can be used indirectly to
   indicate support for realm-based redirection by indicating support
   for the applications concerned.  Designers of new applications MAY
   incorporate the mechanism specified here into their application by
   reference to this document.

   Note that a redirect agent will apply realm-based redirection only
   for those applications that it recognizes to be eligible for such
   treatment.  In typical usage, where a realm has handed off specific
   applications to an alternate realm for processing, this is not an
   issue, since the operator can configure the redirect server for those
   specific applications.

3.  Realm-Based Redirection

   This section specifies an extension to [RFC3588] to achieve realm-

Tsou & Taylor             Expires July 14, 2012                 [Page 3]
Internet-Draft     Realm-Based Redirection In Diameter      January 2012

   based redirection.  The elements of this solution are:

   o  a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD);

   o  one new attribute-value pair (AVP), Redirect-Realm; and

   o  associated behaviour at Diameter nodes implementing this
      specification.

3.1.  Behaviour of Diameter Nodes

3.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
   realm-based routing table for a request contains a realm rather than
   one or more server identities, the redirect agent MUST proceed as
   follows:

   o  If the request contains a Destination-Host AVP or if the request
      is for an application that does not support realm-based
      redirection, the redirect agent MUST set the 'E' bit in the answer
      and set the Result Code to DIAMETER_UNABLE_TO_DELIVER.

         Note that the latter case is actually a matter of
         misconfiguration at the redirect server.

   o  Otherwise, if the request is for an application supporting realm-
      based redirection, the redirect agent MUST set the Result-Code AVP
      to DIAMETER_REALM_REDIRECT_INDICATION rather than
      DIAMETER_REDIRECT_INDICATION.  Furthermore, the redirect agent
      MUST include a Redirect-Realm AVP containing the realm from the
      routing table entry in its answer message instead of one or more
      Redirect-Host AVPs.  All other aspects of Section 6.1.7 remain the
      same as for host-based redirection.

      The redirect agent MAY include a copy of the Redirect-Host-Usage
      AVP, which SHOULD be set to REALM_AND_APPLICATION.  If this AVP is
      added, the Redirect-Max-Cache-Time AVP MUST also be included.
      Note that these AVPs apply to the peer discovered by a node acting
      on the redirect agent's response, as described in the next
      section.  Sections 6.13 and 6.14 of [RFC3588] are modified to
      permit the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs to
      be used also to specify the persistence of cache entries created
      by the Redirect-Realm AVP.

Tsou & Taylor             Expires July 14, 2012                 [Page 4]
Internet-Draft     Realm-Based Redirection In Diameter      January 2012

3.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
   MUST take the following steps:

   1.  Verify that the new realm is authorized to provide the requested
       service.

   2.  If successful, locate and establish a connection to a peer in the
       realm given by the Redirect-Realm AVP, using normal discovery
       procedures as described in Section 5.2 of [RFC3588].

   3.  If again successful:

       *  update its cache of routing entries for the realm and
          application to which the original request was directed, taking
          into account the Redirect-Host-Usage and Redirect-Max-Cache-
          Time AVPs, if present in the answer.

       *  Remove the Destination-Host (if present) and Destination-Realm
          AVPs from the original request and add a new Destination-Realm
          AVP containing the realm identified by the Redirect-Realm AVP
          in the answer.

       *  Forward the modified request.

   Note that the implementation of realm-based redirection will disrupt
   any stateful sessions being served by the given application in the
   interdicted realm.  The transition to realm-based redirection thus
   needs to be managed to minimize the ensuing disruption.

3.2.  The Redirect-Realm AVP

   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
   flag for the Redirect-Realm AVP MUST be set, and the V flag MUST NOT
   be set.

4.  Security Considerations

   Because realm-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

Tsou & Taylor             Expires July 14, 2012                 [Page 5]
Internet-Draft     Realm-Based Redirection In Diameter      January 2012

   authorization check of the path as described in Section 2.10 of
   [RFC3588].

5.  IANA Considerations

   This specification adds a new AVP code [TBD] 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 (3xxx TBD) in the Result-Code AVP
   Values (code 268) - Protocol Errors registry under Authentication,
   Authorization, and Accounting (AAA) Parameters.

6.  Acknowledgements

   Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones,
   Victor Fajardo, Jouni Korhonen, Avi Lior, and Lionel Morand
   contributed comments that helped to shape this document.

7.  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 (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com
   URI:   http://tinatsou.weebly.com/contact.html

Tsou & Taylor             Expires July 14, 2012                 [Page 6]
Internet-Draft     Realm-Based Redirection In Diameter      January 2012

   Tom Taylor (editor)
   Huawei Technologies
   Ottawa
   Canada

   Email: tom.taylor.stds@gmail.com

Tsou & Taylor             Expires July 14, 2012                 [Page 7]