Skip to main content

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

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.
Authors Tina Tsou (Ting ZOU) , Ruibing Hao, Tom Taylor
Last updated 2013-08-02 (Latest revision 2013-07-29)
Replaces draft-tsou-dime-realm-based-redirect
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Lionel Morand
Shepherd write-up Show Last changed 2013-06-27
IESG IESG state Became RFC 7075 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Benoît Claise
Send notices to dime-chairs@tools.ietf.org, draft-ietf-dime-realm-based-redirect@tools.ietf.org
draft-ietf-dime-realm-based-redirect-10
Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Updates: 6733 (if approved)                                       R. Hao
Intended status: Standards Track                           Comcast Cable
Expires: January 29, 2014                                 T. Taylor, Ed.
                                                     Huawei Technologies
                                                           July 28, 2013

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

Abstract

   The Diameter protocol allows a Diameter redirect agent to return to
   the message sender one or more individual hosts as destinations of
   the redirected message.  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.

   This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to
   the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time
   AVPs.

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 January 29, 2014.

Tsou, et al.            Expires January 29, 2014                [Page 1]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

Copyright Notice

   Copyright (c) 2013 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Support of Realm-Based Redirection                     Within
       Applications  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Realm-Based Redirection . . . . . . . . . . . . . . . . . . .   4
     3.1.  Configuration of the Redirecting Server . . . . . . . . .   4
     3.2.  Behaviour of Diameter Nodes . . . . . . . . . . . . . . .   5
       3.2.1.  Behaviour at the Redirect Server  . . . . . . . . . .   5
       3.2.2.  Proxy Behaviour . . . . . . . . . . . . . . . . . . .   5
       3.2.3.  Client Behaviour  . . . . . . . . . . . . . . . . . .   6
     3.3.  The Redirect-Realm AVP  . . . . . . . . . . . . . . . . .   6
     3.4.  DIAMETER_REDIRECT_INDICATION Protocol Error Code  . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The usual redirect indication, as described in Section 6.1.8 and
   Sections 6.12-6.14 of [RFC6733], returns to the message sender one or
   more individual hosts as destination of the redirected message.
   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 to the message sender the alternative
   domain to which redirect the request.  However, the original operator
   should be relieved from configuring in the redirect server a list of
   hosts to contact in the alternative operator's domain, and should

Tsou, et al.            Expires January 29, 2014                [Page 2]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

   simply be able to provide redirect indications to the domain as a
   whole.

1.1.  Terminology

   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 [RFC2119].

   Within this specification, the term "realm-based redirection" is used
   to refer to a mode of operation where a realm rather than an
   individual host is returned as redirect indication.

   The term "redirect server" denotes the device that returns the realm-
   based redirection.  It replaces "redirect agent" in this context for
   reasons explained in the next section.

2.  Support of Realm-Based Redirection Within Applications

   Because realm-based redirection is not part of the Diameter base
   protocol [RFC6733], support of realm-based redirection MUST be
   specified as part of functionality supported by a Diameter
   application.  In this way, support of the considered Diameter
   application (discovered during capabilities exhange procedures as
   defined in Diameter base protocol [RFC6733]) indicates implicit
   support of the realm-based redirection mechanism.  Designers of new
   applications can incorporate the mechanism specified here into their
   application by normative reference to this document.

   The result of making realm-based redirection an application-specific
   behaviour is that it cannot be performed by a redirect agent as
   defined in [RFC6733], but MUST be performed instead by an
   application-aware Diameter node (Diameter server or proxy) (hereafter
   called a "redirect server").  However, despite the change in
   executing role, the behaviour itself is a slight modification of the
   behaviour of a redirect agent as described in Section 2.8.3 of
   [RFC6733].

   An application can specify that realm-based redirection operates only
   on complete sessions beginning with the initial message, or on every
   message within the application, even if earlier messages of the same
   session were not redirected.  This distinction matters only when
   realm-based redirection is first initiated.  In the former case,
   existing sessions will not be disrupted by the deployment of realm-
   based redirection.  In the latter case, existing sessions will be
   disrupted if they are stateful.

Tsou, et al.            Expires January 29, 2014                [Page 3]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

3.  Realm-Based Redirection

   This section specifies an extension of the Diameter base protocol
   [RFC6733] to achieve realm-based redirection.  The elements of this
   solution are:

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

   o  a new attribute-value pair (AVP), Redirect-Realm (code TBD2); and

   o  associated behaviour at Diameter nodes implementing this
      specification.

   This behaviour includes the optional use of the Redirect-Host-Usage
   and Redirect-Max-Cache-Time AVPs.  In this document, these AVPs apply
   to the peer discovered by a node acting on the redirect server's
   response, an extension to their normal usage as described in Sections
   6.13 and 6.14 of [RFC6733].

   Section 3.2.2 and Section 3.2.3 describe how a proxy or client may
   update its routing table for the application and initial realm, as a
   result of selecting a peer in the new realm after realm-based
   redirection.  Note that as a result, the proxy or client will
   automatically route subsequent requests for that application to the
   new realm (with the possible exception of requests within sessions
   already established with the initial realm) until the cached routing
   entry expires.  This should be borne in mind if the rerouting is
   intended to be temporary.

3.1.  Configuration of the Redirecting Server

   A Diameter node (Diameter server or proxy) acting as redirect server
   MUST be configured as follows to execute realm-based redirection:

   o  configured with an application that incorporates realm-based
      redirection;

   o  the Local Action field of the routing table described in
      Section 2.7 of [RFC6733] is set to LOCAL;

   o  an application-specific field is set to indicate that the required
      local action is to perform realm-based redirection;

   o  an associated application-specific field is configured with the
      identities of one or more realms to which the request should be
      redirected.

Tsou, et al.            Expires January 29, 2014                [Page 4]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

3.2.  Behaviour of Diameter Nodes

3.2.1.  Behaviour at the Redirect Server

   As mentioned in Section 2, an application can specify that realm-
   based redirection operates only on complete sessions beginning with
   the initial message (i.e., to prevent disruption of established
   sessions), or on every message within the application, even if
   earlier messages of the same session were not redirected.

   If a redirect server configured as described in Section 3.1 receives
   a request to which realm-based redirection applies, the redirect
   server MUST reply with an answer message with the 'E' bit set, while
   maintaining the Hop-by-Hop Identifier in the header.  The redirect
   server MUST include the Result-Code AVP set to
   DIAMETER_REALM_REDIRECT_INDICATION.  The redirect server MUST also
   include the alternate realm identifier(s) with which it has been
   configured, each in a separate Redirect-Realm AVP instance.

   The redirect server 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
   redirecting server's response, as described in the next section.
   This is an extension of their normal usage as described by Sections
   6.13 and 6.14 of [RFC6733].

      Realm-based redirection MAY be applied even if a Destination-Host
      AVP is present in the request, depending on the operator-based
      policy.

3.2.2.  Proxy Behaviour

   A proxy conforming to this specification that receives an answer
   message with the Result-Code AVP set to
   DIAMETER_REALM_REDIRECT_INDICATION MUST attempt to reroute the
   original request to a server in a realm identified by a Redirect-
   Realm AVP instance in the answer message, and if it fails MUST
   forward the indication toward the client.  To reroute the request, it
   MUST take the following actions:

   1.  Select a specific realm from amongst those identified in
       instances of the Redirect-Realm AVP in the answer message.

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

Tsou, et al.            Expires January 29, 2014                [Page 5]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

   3.  If again successful:

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

       b.  Remove the Destination-Host (if present) and Destination-
           Realm AVPs from the original request and add a new
           Destination-Realm AVP containing the realm selected in the
           initial step.

       c.  Forward the modified request.

   4.  If either of the preceding steps 2-3 fail and additional realms
       have been identified in the original answer, select another
       instance of the Redirect-Realm AVP in that answer and repeat
       steps 2-3 for the realm that it identifies.

3.2.3.  Client Behaviour

   A client conforming to this specification MUST be prepared to receive
   either an answer message containing a Result-Code AVP set to
   DIAMETER_REALM_REDIRECT_INDICATION, or, as the result of proxy
   action, some other result from a realm differing from the one to
   which it sent the original request.  In the case where it receives
   DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same
   steps prescribed in the previous section for a proxy, in order both
   to update its routing table and to obtain service for the original
   request.

3.3.  The Redirect-Realm AVP

   The Redirect-Realm AVP (code TBD2) 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.

3.4.  DIAMETER_REDIRECT_INDICATION Protocol Error Code

   The DIAMETER_REDIRECT_INDICATION (3xxx TBD1) Protocol error code
   indicates that a server has determined that the request within an
   application supporting realm-based redirection could not be satisfied
   locally and the initiator of the request SHOULD direct the request
   directly to a peer within a realm that has been identified in the
   response.  When set, the Redirect-Realm AVP MUST be present.

Tsou, et al.            Expires January 29, 2014                [Page 6]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

4.  Security Considerations

   Realm-based redirection implies a change of the business
   relationships between organizations.  Before redirecting a request
   towards a realm different to the initial realm, the client or proxy
   MUST ensure that the authorization checks have been performed at each
   connection along the path toward the realm identified in the realm-
   based redirect indication.  To perform these authorization checks,
   recommendations given in section 13 of the Diameter base protocol
   [RFC6733] apply.

5.  IANA Considerations

   This specification adds a new AVP code [TBD2] 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 TBD1) 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.  As
   shepherd, Lionel contributed a second set of comments that added
   polish to the document before it was submitted to the IESG.  Benoit
   Claise picked up additional points which were quickly resolved with
   Lionel's help.

7.  Normative References

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

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

Authors' Addresses

Tsou, et al.            Expires January 29, 2014                [Page 7]
Internet-Draft     Realm-Based Redirection In Diameter         July 2013

   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

   Ruibing Hao
   Comcast Cable
   One Comcast Center
   Philadelphia, PA  19103
   USA

   Phone: +1 215 286 3991(O)
   Email: Ruibing_Hao@cable.comcast.com

   Tom Taylor (editor)
   Huawei Technologies
   Ottawa
   Canada

   Email: tom.taylor.stds@gmail.com

Tsou, et al.            Expires January 29, 2014                [Page 8]