idnits 2.17.1 draft-ietf-dime-realm-based-redirect-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC6733, but the abstract doesn't seem to directly say this. It does mention RFC6733 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 RFC6733, updated by this document, for RFC5378 checks: 2006-12-12) -- 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 (October 01, 2013) is 3853 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) == Missing Reference: 'TBD2' is mentioned on line 349, but not defined Summary: 0 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 Huawei Technologies (USA) 4 Updates: 6733 (if approved) R. Hao 5 Intended status: Standards Track Comcast Cable 6 Expires: April 04, 2014 T. Taylor, Ed. 7 Huawei Technologies 8 October 01, 2013 10 Realm-Based Redirection In Diameter 11 draft-ietf-dime-realm-based-redirect-13 13 Abstract 15 The Diameter protocol includes a capability for message redirection, 16 controlled by an application-independent "redirect agent". In some 17 circumstances, an operator may wish to redirect messages to an 18 alternate domain without specifying individual hosts. This document 19 specifies an application-specific mechanism by which a Diameter 20 server or proxy (node) can perform such a redirection when S-NAPTR is 21 not used for dynamic peer discovery. A node performing this new 22 function is referred to as a "Realm-based Redirect Server". 24 This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to 25 the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time 26 AVPs. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 04, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Support of Realm-Based Redirection Within 65 Applications . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . 4 67 3.1. Configuration of the Realm-based Redirect Server . . . . 5 68 3.2. Behaviour of Diameter Nodes . . . . . . . . . . . . . . . 5 69 3.2.1. Behaviour at the Realm-based Redirect Server . . . . 5 70 3.2.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . 6 71 3.2.3. Client Behaviour . . . . . . . . . . . . . . . . . . 6 72 3.3. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . 7 73 3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code . 7 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 7.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The Diameter base protocol [RFC6733] specifies a basic redirection 85 service provided by redirect agent. The redirect indication returned 86 by the redirect agent is described in Section 6.1.8 and Sections 87 6.12-6.14 of [RFC6733], and provides to the message sender one or 88 more individual hosts as destination of the redirected message. 90 However, consider the case where an operator has offered a specific 91 service but no longer wishes to do so. The operator has arranged for 92 an alternative domain to provide the service. To aid in the 93 transition to the new arrangement, the original operator maintains a 94 redirect server to indicate to the message sender the alternative 95 domain to which redirect the request. However, the original operator 96 should be relieved from configuring in the redirect server a list of 97 hosts to contact in the alternative operator's domain, and should 98 simply be able to provide redirect indications to the domain as a 99 whole. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 Within this specification, the term "realm-based redirection" is used 108 to refer to a mode of operation where a realm rather than an 109 individual host is returned as redirect indication. 111 The term "Realm-based Redirect Server" denotes the Diameter node 112 (Diameter server or proxy) that returns the realm-based redirection. 113 The behaviour of the Realm-based Redirect Server itself is a slight 114 modification of the behaviour of a basic redirect agent as described 115 in Section 6.1.8 of [RFC6733]. 117 This document uses a number of terms consistently with their usage in 118 [RFC6733]: "Diameter client", "Diameter node", Diameter peer", 119 "Diameter server", "proxy", "realm" or "domain", "redirect agent", 120 and "session" as defined in Section 1.2, and "application" as defined 121 implicitly by Sections 1.3.4, 2.3, and 2.4. 123 2. Support of Realm-Based Redirection Within Applications 125 The DNS-based dynamic peer discovery mechanism defined in the 126 Diameter base protocol [RFC6733] provides a simple mechanism for 127 realm-based redirection, using the S-NAPTR DDDS application 128 [RFC3958]. When S-NAPTR is used for peer discovery, redirection of 129 Diameter requests from the original realm to a new realm may be 130 performed by updating the existing NAPTR resource records for the 131 original realm as follows: the NAPTR RR for the desired 132 application(s) and supported application protocol(s) provided by the 133 new realm will have an empty FLAG field and the REPLACEMENT field 134 will contain the new realm to use for the next DNS lookup. The new 135 realm can be arbitrary; the restriction in [RFC6733] that the NAPTR 136 replacement field match the domain of the original query does not 137 apply for realm-based redirect purposes. 139 However, the use of DNS-based dynamic peer discovery is optional for 140 Diameter implementations. For deployments which do not make use of 141 S-NAPTR peer discovery, support of realm-based redirection needs to 142 be specified as part of functionality supported by a Diameter 143 application. In this way, support of the considered Diameter 144 application (discovered during capabilities exchange procedures as 145 defined in Diameter base protocol [RFC6733]) indicates implicit 146 support of the realm-based redirection mechanism. A new application 147 specification can incorporate the mechanism specified here by making 148 it mandatory to implement for the application, and referencing this 149 specification normatively. 151 The result of making realm-based redirection an application-specific 152 behaviour is that it cannot be performed by a redirect agent as 153 defined in [RFC6733], but MUST be performed instead by an 154 application-aware Diameter node (Diameter server or proxy) (hereafter 155 called a "Realm-based Redirect Server"). 157 An application can specify that realm-based redirection operates only 158 on complete sessions beginning with the initial message, or on every 159 message within the application, even if earlier messages of the same 160 session were not redirected. This distinction matters only when 161 realm-based redirection is first initiated. In the former case, 162 existing sessions will not be disrupted by the deployment of realm- 163 based redirection. In the latter case, existing sessions will be 164 disrupted if they are stateful. 166 3. Realm-Based Redirection 168 This section specifies an extension of the Diameter base protocol 169 [RFC6733] to achieve realm-based redirection. The elements of this 170 solution are: 172 o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD1); 174 o a new attribute-value pair (AVP), Redirect-Realm (code TBD2); and 176 o associated behaviour at Diameter nodes implementing this 177 specification. 179 This behaviour includes the optional use of the Redirect-Host-Usage 180 and Redirect-Max-Cache-Time AVPs. In this document, these AVPs apply 181 to the peer discovered by a node acting on the redirect server's 182 response, an extension to their normal usage as described in Sections 183 6.13 and 6.14 of [RFC6733]. 185 Section 3.2.2 and Section 3.2.3 describe how a proxy or client may 186 update its routing table for the application and initial realm, as a 187 result of selecting a peer in the new realm after realm-based 188 redirection. Note that as a result, the proxy or client will 189 automatically route subsequent requests for that application to the 190 new realm (with the possible exception of requests within sessions 191 already established with the initial realm) until the cached routing 192 entry expires. This should be borne in mind if the rerouting is 193 intended to be temporary. 195 3.1. Configuration of the Realm-based Redirect Server 197 A Diameter node (Diameter server or proxy) acting as Realm-based 198 Redirect Server MUST be configured as follows to execute realm-based 199 redirection: 201 o configured with an application that incorporates realm-based 202 redirection; 204 o the Local Action field of the routing table described in 205 Section 2.7 of [RFC6733] is set to LOCAL; 207 o an application-specific field is set to indicate that the required 208 local action is to perform realm-based redirection; 210 o an associated application-specific field is configured with the 211 identities of one or more realms to which the request should be 212 redirected. 214 3.2. Behaviour of Diameter Nodes 216 3.2.1. Behaviour at the Realm-based Redirect Server 218 As mentioned in Section 2, an application can specify that realm- 219 based redirection operates only on complete sessions beginning with 220 the initial message (i.e., to prevent disruption of established 221 sessions), or on every message within the application, even if 222 earlier messages of the same session were not redirected. 224 If a Realm-based Redirect Server configured as described in 225 Section 3.1 receives a request to which realm-based redirection 226 applies, the Realm-based Redirect Server MUST reply with an answer 227 message with the 'E' bit set, while maintaining the Hop-by-Hop 228 Identifier in the header. The Realm-based Redirect Server MUST 229 include the Result-Code AVP set to 230 DIAMETER_REALM_REDIRECT_INDICATION. The Realm-based Redirect Server 231 MUST also include the alternate realm identifier(s) with which it has 232 been configured, each in a separate Redirect-Realm AVP instance. 234 The Realm-based Redirect Server MAY include a copy of the Redirect- 235 Host-Usage AVP, which SHOULD be set to REALM_AND_APPLICATION. If 236 this AVP is added, the Redirect-Max-Cache-Time AVP MUST also be 237 included. Note that these AVPs apply to the peer discovered by a 238 node acting on the Realm-based Redirect Server's response, as 239 described in the next section. This is an extension of their normal 240 usage as described by Sections 6.13 and 6.14 of [RFC6733]. 242 Realm-based redirection MAY be applied even if a Destination-Host 243 AVP is present in the request, depending on the operator-based 244 policy. 246 3.2.2. Proxy Behaviour 248 A proxy conforming to this specification that receives an answer 249 message with the Result-Code AVP set to 250 DIAMETER_REALM_REDIRECT_INDICATION MUST attempt to reroute the 251 original request to a server in a realm identified by a Redirect- 252 Realm AVP instance in the answer message, and if it fails MUST 253 forward the indication toward the client. To reroute the request, it 254 MUST take the following actions: 256 1. Select a specific realm from amongst those identified in 257 instances of the Redirect-Realm AVP in the answer message. 259 2. If successful, locate and establish a route to a peer in the 260 realm given by the Redirect-Realm AVP, using normal discovery 261 procedures as described in Section 5.2 of [RFC6733]. 263 3. If again successful: 265 a. update its cache of routing entries for the realm and 266 application to which the original request was directed, 267 taking into account the Redirect-Host-Usage and Redirect-Max- 268 Cache-Time AVPs, if present in the answer. 270 b. Remove the Destination-Host (if present) and Destination- 271 Realm AVPs from the original request and add a new 272 Destination-Realm AVP containing the realm selected in the 273 initial step. 275 c. Forward the modified request. 277 4. If either of the preceding steps 2-3 fail and additional realms 278 have been identified in the original answer, select another 279 instance of the Redirect-Realm AVP in that answer and repeat 280 steps 2-3 for the realm that it identifies. 282 3.2.3. Client Behaviour 284 A client conforming to this specification MUST be prepared to receive 285 either an answer message containing a Result-Code AVP set to 286 DIAMETER_REALM_REDIRECT_INDICATION, or, as the result of proxy 287 action, some other result from a realm differing from the one to 288 which it sent the original request. In the case where it receives 289 DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same 290 steps prescribed in the previous section for a proxy, in order both 291 to update its routing table and to obtain service for the original 292 request. 294 3.3. The Redirect-Realm AVP 296 The Redirect-Realm AVP (code TBD2) is of type DiameterIdentity. It 297 specifies a realm to which a node receiving a redirect indication 298 containing the result code value DIAMETER_REALM_REDIRECT_INDICATION 299 and the Redirect-Realm AVP SHOULD route the original request. 301 3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code 303 The DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD1) Protocol error 304 code indicates that a server has determined that the request within 305 an application supporting realm-based redirection could not be 306 satisfied locally and the initiator of the request SHOULD direct the 307 request directly to a peer within a realm that has been identified in 308 the response. When set, the Redirect-Realm AVP MUST be present. 310 4. Security Considerations 312 The general recommendations given in the section 13 of the Diameter 313 base protocol [RFC6733] apply. Specific security recommendations 314 related to the realm-based redirection defined in this document are 315 described below. 317 Realm-based redirection implies a change of the business 318 relationships between organizations. Before redirecting a request 319 towards a realm different from the initial realm, the client or proxy 320 MUST ensure that the authorization checks have been performed at each 321 connection along the path toward the realm identified in the realm- 322 based redirect indication. Details on Diameter authorization path 323 set-up are given in section 2.9 of [RFC6733]. Section 13 of 324 [RFC6733] provides recommendations on how to authenticate and secure 325 each peer-to-peer connection (using on TLS, DTLS or IPsec) along the 326 way, thus permitting the necessary hop-by-hop authorization checks. 328 Although it is assumed that the administrative domains are secure, a 329 compromised Diameter node acting as Realm-Based Redirect Server would 330 be able to redirect a large number of Diameter requests towards a 331 victim domain which would then be flooded with undesired Diameter 332 requests. Such an attack is nevertheless discouraged by the use of 333 secure Diameter peer-to-peer connections and authorization checks, 334 since these would enable a potential victim domain to discover from 335 where an attack is coming. That in itself, however, does not prevent 336 such a DoS attack. 338 Because realm-based redirection defined in this document implies that 339 the Destination-Realm AVP in a client-initiated request can be 340 changed by a Diameter proxy in the path between the client and the 341 server, any cryptographic algorithm that would use the Destination- 342 Realm AVP as input to the calculation performed by the client and the 343 server would be broken by this form of redirection. Application 344 specifications that would rely on such cryptographic algorithm SHOULD 345 NOT incorporate this realm-based redirection. 347 5. IANA Considerations 349 This specification adds a new AVP code [TBD2] Redirect-Realm in the 350 AVP Code registry under Authentication, Authorization, and Accounting 351 (AAA) Parameters. 353 This specification allocates a new Result-Code value 354 DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD1) in the Result-Code AVP 355 Values (code 268) - Protocol Errors registry under Authentication, 356 Authorization, and Accounting (AAA) Parameters. 358 6. Acknowledgements 360 Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones, 361 Victor Fajardo, Jouni Korhonen, Avi Lior, and Lionel Morand 362 contributed comments that helped to shape this document. As 363 shepherd, Lionel contributed a second set of comments that added 364 polish to the document before it was submitted to the IESG. Benoit 365 Claise picked up additional points which were quickly resolved with 366 Lionel's help. During IETF Last Call Review, Enrico Marocco picked 367 up some important editorial corrections. Stefan Winter contributed 368 text on the use of S-NAPTR as an alternative method of realm-based 369 redirection already specified in [RFC6733]. Derek Atkins performed a 370 review on behalf of the Security Directorate. Lionel noted one more 371 correction. 373 Finally, this document benefited from comments and discussion raised 374 by IESG members Stewart Bryant, Stephen Farrell, Barry Leiba, Pete 375 Resnick, Jaari Arkko, and Sean Turner during IESG review. 377 The authors are very grateful to Lionel Morand for his active role as 378 document shepherd. At each stage, he worked to summarize and resolve 379 comments, making the editor's role easy. Thank you. 381 7. References 383 7.1. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, March 1997. 388 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 389 "Diameter Base Protocol", RFC 6733, October 2012. 391 7.2. Informative References 393 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 394 Service Location Using SRV RRs and the Dynamic Delegation 395 Discovery Service (DDDS)", RFC 3958, January 2005. 397 Authors' Addresses 399 Tina Tsou 400 Huawei Technologies (USA) 401 2330 Central Expressway 402 Santa Clara, CA 95050 403 USA 405 Phone: +1 408 330 4424 406 Email: Tina.Tsou.Zouting@huawei.com 407 URI: http://tinatsou.weebly.com/contact.html 409 Ruibing Hao 410 Comcast Cable 411 One Comcast Center 412 Philadelphia, PA 19103 413 USA 415 Phone: +1 215 286 3991(O) 416 Email: Ruibing_Hao@cable.comcast.com 418 Tom Taylor (editor) 419 Huawei Technologies 420 Ottawa 421 Canada 423 Email: tom.taylor.stds@gmail.com