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

Versions: (draft-tsou-dime-realm-based-redirect) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 7075

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


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

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 January 13, 2011.

Copyright Notice

   Copyright (c) 2010 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



Tsou & Taylor           Expires January 13, 2011                [Page 1]

Internet-Draft     Realm-Based Redirection In Diameter         July 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 4
     3.2.  The Redirect-Realm AVP  . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6






























Tsou & Taylor           Expires January 13, 2011                [Page 2]

Internet-Draft     Realm-Based Redirection In Diameter         July 2010


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 cannot be
   guaranteed without advertisement at the application level.  Designers
   of new applications wishing to include support for realm-based
   redirection can incorporate the mechanism specified here by reference
   to this document.


3.  Realm-Based Redirection

   This section specifies an extension to [RFC3588] to achieve realm-
   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.




Tsou & Taylor           Expires January 13, 2011                [Page 3]

Internet-Draft     Realm-Based Redirection In Diameter         July 2010


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 home server identities, the redirect agent MUST proceed
   as follows:

   o  If the peer from which the request was received did not advertise
      an application incorporating the realm-based routing capability in
      the CER/CEA exchange, the redirect agent SHOULD set the 'E' bit in
      the answer and set the Result Code to DIAMETER_UNABLE_TO_DELIVER.
      As an alternative, the redirect agent MAY if so configured provide
      a host-based redirect as described in Section 6.1.7 of [RFC3588].

   o  Otherwise, if an application supporting the use of realm-based
      redirection was negotiated with the peer, the redirect agent MUST
      set the Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION
      rather than DIAMETER_REDIRECT_INDICATION.  Furthermore, the
      redirect agent MUST a Redirect-Realm AVP containing the realm from
      the routing table entry in its answer message instead of one or
      more Redirect-Host AVPs.  To prevent confusion at Diameter nodes
      receiving the answer message, the message 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.

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
   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 direction provided by the Redirect-Max-
   Cache-Time AVP, if present.  The cache entry SHOULD be associated
   with a redirect usage of REALM_AND_APPLICATION.

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



Tsou & Taylor           Expires January 13, 2011                [Page 4]

Internet-Draft     Realm-Based Redirection In Diameter         July 2010


   containing the result code value DIAMETER_REALM_REDIRECT_INDICATION
   and the Redirect-Realm AVP SHOULD route the original request.  The V
   flag for the Redirect-Realm AVP MUST NOT be set.

   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.


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
   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, and Jouni Korhonen 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.






Tsou & Taylor           Expires January 13, 2011                [Page 5]

Internet-Draft     Realm-Based Redirection In Diameter         July 2010


Authors' Addresses

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

   Email: tena@huawei.com


   Tom Taylor (editor)
   Huawei Technologies
   Ottawa
   Canada

   Email: tom111.taylor@bell.net


































Tsou & Taylor           Expires January 13, 2011                [Page 6]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/