idnits 2.17.1 draft-tsou-dime-realm-based-redirect-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3588, but the abstract doesn't seem to directly say this. It does mention RFC3588 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2009) is 5398 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou 3 Internet-Draft T. Taylor, Ed. 4 Updates: RFC 3588 Huawei Technologies 5 (if approved) July 14, 2009 6 Intended status: Standards Track 7 Expires: January 15, 2010 9 Realm-Based Redirection In Diameter 10 draft-tsou-dime-realm-based-redirect-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 15, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 RFC 3588 allows a Diameter redirect agent to specify one or more 49 individual hosts to which a Diameter message may be redirected by an 50 upstream Diameter node. However, in some circumstances an operator 51 may wish to redirect messages to an alternate domain without 52 specifying individual hosts. This document specifies the means by 53 which this can be achieved. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 59 2. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Behaviour of Diameter Nodes . . . . . . . . . . . . . . . . 3 61 2.1.1. Behaviour at the Redirect Agent . . . . . . . . . . . . 3 62 2.1.2. Behaviour of Other Diameter Nodes . . . . . . . . . . . 4 63 2.2. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . . 4 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The usual redirect indication as described in Section 6.1.7 and 73 Sections 6.12-6.14 of [RFC3588] returns one or more individual host 74 names to the upstream Diameter node. However, consider the case 75 where an operator has offered a specific service but no longer wishes 76 to do so. The operator has arranged for an alternative domain to 77 provide the service. To aid in the transition to the new 78 arrangement, the original operator maintains a redirect server to 79 indicate the alternative destination to upstream nodes. However, the 80 original operator has no interest in configuring a list of hosts in 81 the alternative operator's domain, and would prefer simply to provide 82 redirect indications to the domain as a whole. 84 Within this specification, the term "realm-based redirection" is used 85 to refer to a mode of operation where the redirect indication 86 specifies a realm and the upstream Diameter node reroutes the message 87 to the realm rather than an individual host. 89 1.1. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2. Realm-Based Redirection 97 This section specifies an update to [RFC3588] to achieve realm-based 98 routing. The elements of this solution are: 100 o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011); 102 o a new attribute-value pair (AVP), Redirect-Realm; and 104 o associated behaviour at Diameter nodes implementing this 105 specification. 107 2.1. Behaviour of Diameter Nodes 109 2.1.1. Behaviour at the Redirect Agent 111 This specification modifies Section 2.7 of [RFC3588] to permit 112 REDIRECT routing table entries to contain an alternative realm 113 instead of individual home server identities. 115 This specification modifies Section 6.1.7 of [RFC3588]. If the 116 realm-based routing table for a request contains a realm rather than 117 one or more home server identities, the redirect agent MUST set the 118 Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION rather than 119 DIAMETER_REDIRECT_INDICATION. Furthermore, the redirect agent MUST 120 insert a Redirect-Realm AVP containing the realm from the routing 121 table entry in its answer message instead of one or more Redirect- 122 Host AVPs. To prevent confusion at Diameter nodes receiving the 123 answer message, the Result-Code AVP MUST include the Error-Reporting- 124 Host AVP if the host setting the Result-Code AVP is different from 125 the identity encoded in the Origin-Host AVP, in conformity with 126 Section 7.1 of [RFC3588]. All other aspects of Section 6.1.7 remain 127 the same as for host-based redirection. 129 2.1.2. Behaviour of Other Diameter Nodes 131 A Diameter node conforming to this specification which receives an 132 answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION 133 SHOULD attempt to reroute the request to the indicated realm rather 134 than the individual host(s) specified in Redirect-Host AVP(s) in the 135 redirect indication. 137 2.2. The Redirect-Realm AVP 139 The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It 140 specifies a realm to which a node receiving a redirect indication 141 containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION 142 and this AVP SHOULD route the original request. The M and V flags 143 for the Redirect-Realm AVP MUST NOT be set. 145 3. Security Considerations 147 Because real-based redirection implies a change in business 148 relationships, the node acting on the redirect indication SHOULD 149 verify that the new realm is authorized to perform the requested 150 service. Similarly the originator of the request SHOULD perform an 151 authorization check of the path as described in Section 2.10 of 152 [RFC3588]. 154 4. IANA Considerations 156 This specification adds a new AVP code [286???] Redirect-Realm in 157 the AVP Code registry under Authentication, Authorization, and 158 Accounting (AAA) Parameters. 160 This specification allocates a new Result-Code value 161 DIAMETER_REALM_REDIRECT_INDICATION (3011) in the Result-Code AVP 162 Values (code 268) - Protocol Errors registry under Authentication, 163 Authorization, and Accounting (AAA) Parameters. 165 5. Acknowledgements 167 Glen Zorn, Sebastien Decugis, and Wolfgang Steigerwald contributed 168 comments that helped to shape this document. 170 6. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 176 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 178 Authors' Addresses 180 Tina Tsou 181 Huawei Technologies 182 Bantian, Longgang District 183 Shenzhen 518129 184 P.R. China 186 Email: tena@huawei.com 188 Tom Taylor (editor) 189 Huawei Technologies 190 1852 Lorraine Ave 191 Ottawa 192 Canada 194 Email: tom.taylor@rogers.com