One document matched: draft-tsou-dime-realm-based-redirect-01.txt

Differences from draft-tsou-dime-realm-based-redirect-00.txt

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


                  Realm-Based Redirection In Diameter
                draft-tsou-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 15, 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 15, 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 AVP  . . . . . . . . . . . . . . . . . . 4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5






























Tsou & Taylor           Expires January 15, 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  a new attribute-value pair (AVP), Redirect-Realm; 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
   realm-based routing table for a request contains a realm rather than



Tsou & Taylor           Expires January 15, 2010                [Page 3]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


   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.  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 rather
   than the individual host(s) specified in Redirect-Host AVP(s) in the
   redirect indication.

2.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
   containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION
   and this AVP SHOULD route the original request.  The M and V flags
   for the Redirect-Realm AVP MUST NOT be set.


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


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,



Tsou & Taylor           Expires January 15, 2010                [Page 4]

Internet-Draft     Realm-Based Redirection In Diameter         July 2009


   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 15, 2010                [Page 5]