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]