idnits 2.17.1 draft-tsou-diameter-explicit-routing-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 611 has weird spacing: '... relays prox...' == Line 646 has weird spacing: '...example rec...' == Line 647 has weird spacing: '...example rec...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 2010) is 5057 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Tsou 3 Internet-Draft Huawei Technologies 4 Intended status: Informational G. Zorn 5 Expires: December 24, 2010 Network Zen 6 T. Taylor, Ed. 7 Huawei Technologies 8 June 22, 2010 10 Session-Specific Explicit Diameter Request Routing 11 draft-tsou-diameter-explicit-routing-05 13 Abstract 15 This document describes a mechanism to enable specific Diameter 16 proxies to remain in the path of all message exchanges constituting a 17 Diameter session. This document is being published to provide the 18 basis for a standardized solution to a problem raised by some 19 architectures (e.g., WLAN 3GPP IP access, 3GPP TS23.234) that use 20 Diameter. The intended use will be as a reference within the non- 21 IETF specification of a Diameter application that meets the needs of 22 these architectures. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 24, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. The 3GPP Wireless LAN (WLAN) Access Architecture . . . . . . . 5 73 3.1. Maintaining the Routing Path . . . . . . . . . . . . . . . 6 74 4. Diameter Explicit Routing (ER) . . . . . . . . . . . . . . . . 6 75 4.1. Originating a request (ER-Originator) . . . . . . . . . . 7 76 4.2. Relaying and Proxying Requests (ER-Proxy) . . . . . . . . 9 77 4.3. Receiving Requests (ER-Destination) . . . . . . . . . . . 11 78 4.4. Diameter answer processing . . . . . . . . . . . . . . . . 12 79 4.5. Failover and Failback Considerations . . . . . . . . . . . 12 80 4.6. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 12 81 4.6.1. Explicit-Path-Record AVP . . . . . . . . . . . . . . . 13 82 4.6.1.1. Proxy-Realm AVP . . . . . . . . . . . . . . . . . 13 83 4.6.2. Explicit-Path AVP . . . . . . . . . . . . . . . . . . 13 84 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 13 85 4.8. Example Message Flow . . . . . . . . . . . . . . . . . . . 14 86 5. RADIUS/Diameter Protocol Interactions . . . . . . . . . . . . 16 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 In the Diameter base protocol [RFC3588], the routing of request 98 messages is based solely on the routing decisions made separately by 99 each node along the path. [RFC5729] has added the ability to force 100 messages to pass through a specified set of realms through the use of 101 NAI decoration. However, no other specification provides the ability 102 to force routing through a specific set of agents. Therefore, in a 103 topology where multiple paths exist from source to destination, there 104 is no guarantee that all messages relating to a given session will 105 take the same path. In general, this has not caused problems, but 106 some architectures (e.g., WLAN 3GPP IP access [TS23.234]) require 107 that once certain agents become engaged in a session, they are able 108 to process all subsequent messages for that session. 110 While the solution presented in this document is valid, it violates 111 one of the basic premises of Diameter, the robustness of its 112 architecture. With normal Diameter routing, sessions will survive 113 failures of agents along the routing path. With the proposals in 114 this document, routing becomes pinned to specific agents whose 115 failure will terminate the session. The IETF does not endorse this 116 specification because of its impact on Diameter session 117 survivability, but do not object to its publication for use in 118 specialized situations where the loss of robustness is acceptable. 120 The authors see no interaction between explicit routing and the 121 specific applications with which it is employed. Hence in principle 122 it can be added to existing applications if they support the 123 necessary extensibility, and equally can be used with new 124 applications. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 The following terms are used to define the functionality and 133 participants in the routing extensions described in this document. 135 ER 136 Explicit routing, the mechanism provided by this specification to 137 allow proxies traversed by the initial message of a session to 138 ensure that they remain on the messaging path for all subsequent 139 request messages of a session. 141 ER-proxy 142 A proxy that implements the ER mechanism and can therefore use it 143 to remain in the path for subsequent messages of a session. 145 ER-Destination 146 A Diameter node which is capable of participating in ER and which 147 will ultimately consume the request sent by an ER-Originator. 149 ER-Originator 150 A Diameter node initiating a session and sending the requests. 151 The ER- Originator can be any Diameter node sending a request, 152 i.e. client, server or proxy capable of initiating sessions and 153 participating in ER. 155 AAA Relays 156 Other Diameter nodes interspersed between the ER-Originator, ER- 157 Proxies, and the ER-Destination. These nodes represent existing 158 Diameter agents and proxies that do not participate in ER and do 159 not recognize Explicit-Path AVPs. 161 3. The 3GPP Wireless LAN (WLAN) Access Architecture 163 One example of a system requiring that certain agents (stateful 164 proxies, in this case) remain in the forwarding path of all session 165 messages is the 3GPP WLAN IP access architecture [TS23.234]. The 166 3GPP WLAN interworking architecture extends 3GPP services to the WLAN 167 access side, enabling a 3GPP subscriber to use a WLAN to access 3GPP 168 services. 170 WLAN AAA provides access to the WLAN to be authenticated and 171 authorized through the 3GPP system. This access control can permit 172 or deny a subscriber the access to the WLAN system and/or the 3GPP 173 system. 175 There are two 3GPP WLAN interworking reference models: 177 1. In the non-roaming case, the model includes the WLAN access 178 network and the 3GPP AAA server in the home network. The 3GPP 179 AAA server is responsible for access control as well as charging. 181 2. In the roaming case, the model includes the WLAN access network, 182 the 3GPP AAA proxy in the visited network and the 3GPP AAA server 183 in the home network. The 3GPP AAA server is responsible for 184 access control. Charging records may be generated by the AAA 185 proxy and/or the AAA server. The AAA proxy relays access control 186 and charging messages to the AAA server. The AAA proxy will also 187 do offline charging, if required. 189 The roaming case presents two problems for which the Diameter routing 190 mechanism described in [RFC3588] does not offer any unambiguous and 191 standard solution. 193 Network Selection 194 Selecting an initial message path for the Diameter session through 195 (possibly many) alternative visited network(s) to the home 196 network. 198 Explicit Routing 199 Maintaining the selected message path for all messages in the 200 Diameter session. 202 The former is outside the scope of this document; the latter is 203 described in detail below. 205 3.1. Maintaining the Routing Path 207 After a successful authentication, a Diameter session is established 208 involving (at least) the following stateful entities: 210 o the Diameter client in the WLAN access node, 212 o a Diameter proxy (the 3GPP AAA proxy) in the visited mobile 213 network, and 215 o a Diameter server in the user's home realm. 217 The functions assigned to the 3GPP AAA proxy include: 219 o Reporting charging information to the offline charging system in 220 the visited network 222 o Policy enforcement based on roaming agreements 224 o Service termination initiated by the visited network operator 226 These functions all require that state be maintained within the 227 visited network. The 3GPP choice is to maintain that state at the 228 3GPP AAA proxy. This means that the latter must remain in the 229 messaging path for all subsequent messages relating to the same 230 session. 232 4. Diameter Explicit Routing (ER) 234 This section outlines a Diameter ER mechanism by which Diameter nodes 235 participating in ER can remain in the path of all request messages 236 for a specific session. A new Explicit-Path AVP is defined to enable 237 ER participants to manipulate the Destination-Host and/or 238 Destination-Realm AVPs of request messages in order to ensure the 239 correct routing behavior. The following sections describe the 240 extensions to the request routing in [RFC3588] to implement the ER 241 mechanism. The proposed extensions utilize existing routing 242 strategies in [RFC3588] and do not mandate modifications to it. The 243 scheme also differs from existing strict source routing schemes in 244 which all hops in the path have to participate. In the ER mechanism, 245 only Diameter nodes interested in participating in the ER scheme will 246 be involved in it. 248 4.1. Originating a request (ER-Originator) 250 A Diameter node acting as an ER-Originator for a particular session 251 MUST maintain a local cache which enumerates all the Diameter 252 identities of the ER- Proxies that the request messages must traverse 253 along the path to the ER- Destination. The identity of a Diameter 254 node is defined in [RFC3588]. The local cache may also include the 255 node's realm. The data structure of the cache is left up to the 256 implementation and should persist as part of the session attributes 257 or properties. 259 An ER-Originator sending request messages MUST add an Explicit-Path 260 AVP to these requests. The contents of the cache SHOULD be used to 261 populate the Explicit-Path AVP where each cached entry is represented 262 by a corresponding instance of the Explicit-Path-Record AVP. ER- 263 Proxies along the path of the request message MUST examine the 264 contents of the Explicit-Path AVP and make routing adjustments based 265 on records it contains. An example of the message flow is shown in 266 Section 4.8. Note that the ER-Originator can be any Diameter node, 267 i.e. client, server or proxy. 269 The ER-Originator can populate the cache either by pre-configuring 270 its contents or by using the first request message of the session to 271 gather identities of participating ER-Proxies along the routing path. 272 The latter scheme is known as Explicit-Path discovery. The contents 273 of the cache can be pre-configured if the ER-Originator has explicit 274 knowledge of the ER-Proxies the request messages must traverse; 275 otherwise it can use Explicit-Path discovery. It is recommended that 276 Explicit-Path discovery be used whenever possible since pre- 277 configuration is less flexible by nature. 279 Explicit-Path discovery is useful if the identities of the ER-Proxies 280 are not known or if there are several ER capable proxies (a cluster 281 of proxies) that can be dynamically chosen based on other routing 282 policies. In Explicit-Path discovery, the cache of the ER-originator 283 is initially empty. When the ER-Originator sends the first request 284 message of a session, the Explicit-Path AVP will contain only one 285 Explicit-Path-Record AVP with the identity and/or the realm of the 286 ER-Originator. The Destination-Host and/or Destination-Realm AVP of 287 the request message is set to the identity and/or the realm of the 288 ER-Destination respectively as specified in [RFC3588]. 290 It should be noted that ER-Originator initial request message 291 routing procedures and the population of Destination-Realm may be 292 affected by the User- Name AVP NAI decoration [RFC5729]. NAI 293 decoration is a form of request message source routing and defines 294 realms that the request message must traverse through before 295 routing towards the ER- Destination. Diameter nodes participating 296 to the request message routing must examine and process the User- 297 Name AVP, and modify the Destination-Realm AVP accordingly as long 298 as there are realms left in the decorated NAI. Source routing 299 based upon NAI decoration does not affect the Explicit-Path 300 discovery as defined in this document. 302 When the request message is received and processed by an ER-Proxy, 303 the ER- Proxy MUST append a new Explicit-Path-Record containing its 304 own identity and/or realm to the Explicit-Path AVP prior to 305 forwarding the message. Subsequent ER-Proxies along the path that 306 wish to participate in the ER MUST also append their own Explicit- 307 Path-Record in the same manner (Section 4.2). When the request 308 reaches the ER-Destination, it MUST append a new Explicit- Path- 309 Record to the Explicit-Path AVP in a similar manner. The ER- 310 Destination MUST copy the resulting Explicit-Path AVP to the answer 311 message (Section 4.3). Once the answer message reaches the ER- 312 Originator, the Explicit-Path AVP will contain one or more Explicit- 313 Path-Records containing the ER-Originator's identity, the identities 314 of all participating ER-Proxies and the identity of the ER- 315 Destination. The ER-Originator SHOULD populate its local cache with 316 the contents of the Explicit-Path AVP received in this initial answer 317 message. 319 If the answer message does not contain an Explicit-Path AVP or the 320 Result- Code AVP is set to Diameter_ER_NOT_AVAILABLE (Section 4.7), 321 it is an indication to the ER-Originator that the destination of the 322 request does not support ER and that the ER-Originator SHOULD avoid 323 sending an Explicit-Path AVP in subsequent request messages. 325 If, after performing Explicit-Path discovery, the Explicit-Path AVP 326 in the answer message contains only the Explicit-Path-Record of the 327 ER-Originator and ER-Destination then this SHOULD be an indication to 328 the ER-Originator that there are no Diameter proxies capable of 329 participating in ER along the path and that the ER-Originator SHOULD 330 NOT send an Explicit-Path AVP in subsequent request messages of this 331 session. See Section 4.5 for more discussion. In such cases, the 332 situation may be transient and Explicit-Path discovery in succeeding 333 sessions may find participating proxies. It is left up to the ER- 334 Originator to decide if Explicit-Path discovery should be attempted 335 in succeeding sessions. 337 Once the ER-Originator's local cache has been populated, whether by 338 pre- configuration or through Explicit-Path discovery, all request 339 messages for the session MUST include the Explicit-Path AVP using the 340 contents of the local cache. The Explicit-Path AVP MUST contain the 341 Explicit-Path-Records of all the nodes enumerated in the cache except 342 that of the ER-Originator itself. The identities enumerated in the 343 Explicit-Path AVP MUST appear in the order they will be traversed in 344 the routing path. The last entry in the Explicit-Path AVP MUST be 345 the Explicit-Path-Record of the ER-Destination. In addition, the 346 value of the Destination-Host and/or Destination-Realm AVP of the 347 request messages MUST be set to the value of the Proxy-Host and/or 348 Proxy- Realm of the first Explicit-Path-Record AVP present in the 349 Explicit-Path AVP. 351 This ensures that the ER-Originator as well as any AAA relays in 352 between the ER-Originator and the first ER-Proxy will route the 353 message towards the first ER-Proxy as specified in RFC3588 354 [RFC3588]. 356 Subsequent actions taken by the first ER-Proxy upon receipt of the 357 message are described in Section 4.2 and will mimic those of the ER- 358 Originator. 360 Answer messages received by the ER-Originator to subsequent request 361 messages after the ER path has been established SHOULD NOT have an 362 Explicit- Path AVP. Otherwise, this SHOULD be considered a suspect 363 condition that may be caused by a misbehaving ER participant. It is 364 left up to the ER-Originator whether to continue using the ER scheme 365 when such a condition arises or to attempt another Explicit-Path 366 discovery on subsequent sessions. 368 4.2. Relaying and Proxying Requests (ER-Proxy) 370 The basic action taken by an ER-Proxy upon receiving a request is to 371 check whether explicit routing is supported in the request and if so, 372 check whether it is already a participant in explicit routing for the 373 said request. If it is an existing participant, the ER-Proxy MUST 374 pop/remove the Explicit-Path-Record AVP pertaining to itself from the 375 Explicit-Path AVP and then use the next Explicit-Path-Record AVP for 376 subsequent routing. Details of this operation are as follows. 378 An ER-Proxy is not required to keep local state or cache state 379 regarding the explicit routing procedure. However, it MUST check 380 whether an incoming request contains an Explicit- Path AVP. 382 1. If an incoming request does not contain an Explicit-Path AVP then 383 the ER- Proxy MUST process and forward the request as specified 384 in [RFC3588]. 386 2. If the incoming request contains an Explicit-Path AVP, the ER- 387 Proxy MUST check whether its identity is present in the Explicit- 388 Path AVP. Determining whether its identity is present can be 389 done by matching its identity to the Proxy-Host AVPs contained in 390 each Explicit-Path-Record. 392 A. If its identity is not present and it wishes to participate 393 in explicit routing, the ER-Proxy MUST append a new Explicit- 394 Path-Record as the last AVP in the Explicit-Path AVP prior to 395 forwarding the request. The new Explicit-Path-Record MUST 396 contain at the least a Proxy-Host AVP set to the proxy's 397 identity. This scenario is part of the Explicit-Path 398 discovery scheme described in Section 4.1. 400 B. However, if its identity is not present and the ER-Proxy does 401 not wish to participate in the ER, it SHOULD NOT modify the 402 Explicit-Path AVP and SHOULD simply forward the request as 403 specified in [RFC3588] using the existing value of 404 Destination-Host and/or Destination-Realm AVP. Non ER- 405 proxies and relays that do not support ER and do not 406 recognize Explicit-Path AVP will take the same action. 408 C. If the identity of the ER-Proxy is present in the Explicit- 409 Path AVP, then it MUST be the first Explicit-Path-Record in 410 the AVP; otherwise, this SHOULD be considered an error and an 411 answer message with the e-bit set and the Result- Code set to 412 Diameter_INVALID_PROXY_PATH_STACK must be sent back to the 413 ER- Originator (Section 4.7). If the identity of the ER- 414 Proxy matches the first Explicit-Path-Record, the ER-Proxy 415 MUST remove this record from Explicit-Path AVP and set the 416 Destination-Host and/or Destination-Realm AVP to the next 417 Explicit-Path-Record present in the Explicit-Path AVP. 418 Setting the Destination-Host and/or Destination-Realm AVP 419 will ensure that the ER-Proxy as well as all AAA relays in 420 between the current ER-Proxy and the next ER-Proxy enumerated 421 in the Explicit-Path AVP will route the message towards the 422 next ER-Proxy. The process of removing the ER-Proxy's record 423 is analogous to removing an entry in a stack represented by 424 the Explicit-Path AVP. 426 Note that in the case of the ER-Destination, the Explicit-Path AVP 427 MUST be empty once its own record is removed (Section 4.3). Note 428 also that the behavior specified above applies to a Diameter node 429 that acts as a relay agent and participates in the ER scheme. 431 4.3. Receiving Requests (ER-Destination) 433 A Diameter node that locally processes requests sent by the ER- 434 Originator (Section 4.1) and is able to support ER (an ER- 435 Destination) MUST check for the presence of an Explicit-Path AVP in 436 the request message. 438 1. If an incoming request does not contain an Explicit-Path AVP then 439 it is an indication that messages belonging to this session will 440 not use ER. The Diameter node SHOULD process the request for 441 local consumption and formulate an answer message as specified in 442 [RFC3588]. 444 2. If the incoming request contains an Explicit-Path AVP, the 445 Diameter node MUST check whether its identity is present in the 446 Explicit-Path AVP. 448 A. If its identity is not present in the Explicit-Path and it 449 wishes to participate in the ER, the Diameter node MUST 450 append a new Explicit-Path-Record to the Explicit-Path AVP in 451 the received message. The new Explicit-Path-Record MUST 452 contain at the least a Proxy-Host AVP set to the ER- 453 Destination's identity. The ER-Destination MUST then copy 454 the resulting Explicit-Path AVP to the subsequent answer 455 message. This scenario is part of the proxy path discovery 456 scheme described in Section 4.1. 458 B. If its identity is not present and the ER-Destination 459 supports ER but does not wish to or cannot participate, it 460 MAY send a Result-Code AVP set to Diameter_ER_NOT_AVAILABLE 461 as defined in Section 4.7. The ER-Destination SHOULD NOT 462 include any Explicit-Path AVP in the subsequent answer. The 463 same scenario applies to ER-destinations that do not support 464 ER and do not recognize Explicit-Path AVP and is a hint to 465 the ER-Originator that the destination does not support ER. 467 C. If the identity of the ER-Destination matches a record in the 468 Explicit-Path AVP, then it MUST be the only Explicit-Path- 469 Record present in the Explicit-Path AVP otherwise, this 470 SHOULD be considered an error and an answer message with the 471 'E' bit set and containing an Experimental-Result-Code AVP 472 with the set to Diameter_INVALID_PROXY_PATH_STACK MUST be 473 sent back to the ER-Originator (Section 4.7). If the 474 identity of the of the ER-Destination matches the only 475 existing Explicit-Path-Record, then this is an indication of 476 a successful ER, but with no participating ER-Proxies. The 477 ER-Destination SHOULD NOT copy the Explicit-Path AVP into the 478 subsequent answer message. 480 4.4. Diameter answer processing 482 There is no requirement on Diameter nodes participating in ER to 483 provide special handling or routing of answer messages. Answer 484 messages SHOULD be processed normally as specified in [RFC3588]. 485 However, a Diameter node acting as an ER-Destination MUST formulate a 486 proper Explicit-Path AVP in answer messages as described in 487 Section 4.3. 489 4.5. Failover and Failback Considerations 491 If there is no ER-Proxy along the selected path, the answer message 492 will contain an Explicit-Path AVP that contains only the Explicit- 493 Route-Records of the ER-Originator and the ER-Destination, indicating 494 that there is no ER support found in Diameter nodes along the path. 495 It is left to the ER-Originator to continue with processing of the 496 request without ER support or terminate the session. The ER- 497 Originator SHOULD NOT attempt to perform Explicit-Path discovery in 498 subsequent request messages of this session in such cases so as to 499 protect against failback conditions where an ER-Proxy suddenly 500 appears in the path and attempts to add a new Explicit-Path-Record 501 for request messages other than the initial request. 503 Allowing an ER-Proxy to join the session after the initial request 504 is permissible only if the application requirements do not mandate 505 that any participating ER-Proxy receive all of the messages of a 506 session. 508 However, based on local policy, the ER-Originator MAY attempt 509 Explicit-Path discovery in subsequent sessions. 511 If a failover occurs in a Diameter node preceding an ER-Proxy when 512 the ER path is already established, it is possible that an 513 Diameter_UNABLE_TO_DELIVER error will be received by the ER- 514 Originator if there are no alternative paths towards the ER-proxy. 515 In such a case, it is left to the ER-Originator to handle the error 516 as specified in Diameter application or in [RFC3588]. 518 4.6. Attribute-Value Pairs 520 The following sections define the AVPs used in the ER process. All 521 of these AVPs MUST have the 'V' bit set and the 'M' bit cleared, with 522 the Vendor-ID field set to 2011 (as assigned in 523 http://www.iana.org/assignments/enterprise-numbers). 525 4.6.1. Explicit-Path-Record AVP 527 The Explicit-Path-Record AVP (AVP Code 35001) is of type Group. The 528 identity added in the Proxy-Host [RFC3588] element of this AVP MUST 529 be the same as the one advertised by the Diameter node in the Origin- 530 Host AVP during the Capabilities Exchange messages. 532 Explicit-Path-Record ::= < AVP Header: 35001 > 533 { Proxy-Host } 534 [ Proxy-Realm ] 536 4.6.1.1. Proxy-Realm AVP 538 The Proxy-Realm AVP (AVP Code 35002) is of type DiameterIdentity, and 539 contains the realm of the ER node inserting the record. 541 It is recommended that the Proxy-Host AVP be present and used to 542 uniquely identify an ER-Proxy within the AAA realm being traversed by 543 a request. Otherwise, ER will need to rely on realm routing. Realm 544 routing would require a well-known topology for the ER scheme to work 545 properly since the hostname of the proxy is not specified. In such a 546 case, the Proxy-Realm AVP MUST be present and is used to identify the 547 ER-Proxy of the realm. 549 When a Proxy-Host AVP is present in the Explicit-Path-Record AVP, the 550 realm name included in the hostname MUST correspond to the identity 551 present in the Proxy-Realm AVP. 553 4.6.2. Explicit-Path AVP 555 The Explicit-Path AVP (AVP Code 35003) is of type Grouped. This AVP 556 SHOULD be present in all request and answer messages performing ER. 558 Explicit-Path ::= < AVP Header: 35003 > 559 1* [ Explicit-Path-Record ] 560 * [ AVP ] 562 4.7. Error Handling 564 The following error conditions may occur during ER processing. All 565 error indications MUST be encapsulated in an instance of the 566 Experimental- Result AVP [RFC3588] with the Vendor-Id AVP set to 2011 567 and the Experimental-Result-Code set as specified below. 569 DIAMETER_INVALID_PROXY_PATH_STACK 3501 570 A request message received by an ER-Proxy or ER-Destination after 571 an ER path has been established has the first or only Explicit- 572 Path-Record AVP not matching the ER-Proxy or the ER-Destinations 573 identity. The same error applies to ER-Destinations receiving a 574 Explicit-Path-AVP containing more than one Explicit-Path-Record or 575 an Explicit-Path-AVP with only one Explicit-Path-Record not 576 matching its own identity. 578 This error SHOULD be considered a protocol failure and SHOULD be 579 treated on a per-hop basis; Diameter proxies may attempt to 580 correct the error, if possible. Diameter answer messages 581 containing this error indication MUST have the 'E' bit set and 582 MUST conform to Section 7.2 of [RFC3588]. 584 DIAMETER_ER_NOT_AVAILABLE 4501 585 An ER-Destination which supports ER routing but is unable to 586 comply for unknown reasons MAY send an answer message with the 587 Result-Code AVP set to this error code. This error value SHOULD 588 be considered a transient failure indicating that subsequent ER 589 attempts may succeed. 591 4.8. Example Message Flow 593 The example presented here illustrates the flow of Diameter messages 594 with the typical attributes present in the ER scenario. 596 The ER-Originator in the example below shows the use of Explicit-Path 597 discovery with the first request. However, the ER-Originator may 598 also use a pre-configured cache. The ER-Originator can be any 599 Diameter node sending a request, i.e. client, server or proxy. In 600 this scenario, the local cache of the ER-Originator is initially 601 empty. 603 The AAA relays in between the ER-Proxies, ER-Originator and ER- 604 Destination may or may not be present and are shown here to depict 605 routing paths that the requests may take prior to being processed by 606 nodes participating in the ER scheme. The AAA relays also depict 607 existing Diameter relays or proxies that do not recognize Explicit- 608 Path AVPs and therefore do not participate in ER. 610 ER- ER- ER- ER- 611 Originator AAA relays proxy1 AAA relays proxy2 Destination 612 (o.r1 (p.r1 (p.r2 (d.r2 613 .example) .example) .example) .example) 614 | | | | | 615 cache=(empty) | | | | | 616 ------------->|--------->| | | | 617 (1st request of the session)| | | | 618 Explicit-Path= | | | | 619 o.r1.example,r1.example | | | 620 dest-host=d.r2.example | | | | 621 dest-realm=r2.example | | | | 622 | | | | | 623 | |--------->|--------->| | 624 | | (forwarded request)| | 625 | | Explicit-Path= | | 626 | | record1=o.r1.example,reaml1.example 627 | | record2=p.r1.example,r1.example 628 | | dest-host=d.r2.example | 629 | | dest-realm=r2.example | 630 | | | | | 631 | | | |--------->| 632 | | | (forwarded request) 633 | | | Explicit-Path= 634 | | | record1=o.r1.example, 635 | | | r1.example 636 | | | record2=p.r1.example, 637 | | | r1.example 638 | | | record3=p.r2.example, 639 | | | r2.example 640 | | | dest-host=d.r2.example 641 | | | dest-realm=r2.example 642 | | | | | 643 cache= |<---------|<---------|<---------|<---------| 644 record1=o.r1.example,r1.example (answer) | 645 record2=p.r1.example,r1.example Explicit-Path= 646 record3=p.r2.example,r2.example record1=o.r1.example,r1.example 647 record4=d.r2.example,r2.example record2=p.r1.example,r1.example 648 | | record3=p.r2.example,r2.example 649 | | record4=d.r2.example,r2.example 650 Note: An originator pre-configuring | | | 651 its local cache can skip the | | | 652 exchange above and send the | | | 653 initial request as shown below | | | 654 | | | | | 655 ------------->|--------->| | | | 656 (subsequent request of the session) | | | 657 Explicit-Path= | | | | 658 record1=p.r1.example,r1.example | | | 659 record2=p.r2.example,r2.example | | | 660 record3=d.r2.example,r2.example | | | 661 dest-host=p.r1.example | | | | 662 dest-realm=r1.example | | | | 663 | |--------->|--------->| | 664 | | (forwarded request)| | 665 | | Explicit-Path= | | 666 | | record1=p.r2.example,r2.example 667 | | record2=d.r2.example,r2.example 668 | | dest-host=p.r2.example | 669 | | dest-realm=r2.example | 670 | | | | | 671 | | | |--------->| 672 | | | (forwarded request) 673 | | | Explicit-Path 674 | | | record1=d.r2.example, 675 | | | r2.example 676 | | | dest-host=d.r2.example 677 | | | dest-realm=r2.example 678 | | | | | 679 cache= |<---------|<---------|<---------|<---------| 680 record1=o.r1.example,r1.example (answer) | | 681 record2=p.r1.example,r1.example * no Explicit-Path-AVP present 682 record3=p.r2.example,r2.example | | | 683 record4=d.r2.example,r2.example | | | 684 | | | | | 685 | | | | | 686 (subsequent request of the session will repeat the process above) 687 | | | | | 688 | | | | | 690 Figure 1: Example ER Message Flow 692 5. RADIUS/Diameter Protocol Interactions 694 No actions need to be taken with regards to RADIUS/Diameter 695 interaction. The routing extension described in this document is 696 transparent to any translation gateway and relevant only to Diameter 697 routing. The assumption is that if there is a RADIUS proxy chain 698 between Diameter translation agents the route between translation 699 agents remains stable during the session and does not cause an 700 invalidation of the proxy path stack. 702 6. IANA Considerations 704 Because this document defines only vendor-specific AVPs and result 705 codes, no IANA actions are necessary. 707 7. Security Considerations 709 The security considerations in [RFC3588] apply to this extension. In 710 addition, this extension raises questions of authorization and can 711 potentially allow a new denial of service attack. 713 The authorization issue comes about because the proxies that 714 participate in ER are self-selected. An ER-Proxy is able, through 715 the operation of ER, to guarantee that it can monitor every message 716 of a session. This is in contrast to ordinary Diameter routing, 717 where some messages may pass by an alternate route. The question is 718 whether the originating party is prepared to extend this additional 719 degree of trust to arbitrary parties along the path. If not, the ER- 720 Originator requires a mechanism to determine whether an ER-Proxy 721 listed in the returned Explicit-Path AVP can be trusted. If it has 722 such a mechanism, then an unwanted ER-Proxy can be deleted from its 723 cache and thus not appear in the ER- Path AVP in subsequent requests. 724 This specification assumes that the originating party is either 725 prepared to allow arbitrary Diameter nodes along the path to attach 726 themselves to the session as ER-Proxies, or else the ER- Originator 727 maintains a pre-configured list of ER-Proxies in its cache. 729 The potential denial of service attack is not a serious one because 730 the same result can be obtained more directly. An attacker with 731 control of a Diameter node along the path of the original request 732 could insert an Explicit-Path- Record containing the identity of 733 another node or a non-existent node, rather than its own identity. 734 Routing subsequent messages of the session through another node could 735 result in violation of the trust assumptions made upstream. Routing 736 subsequent messages to a non-existent node causes them to be lost and 737 terminates the session. It would seem simpler to perpetrate whatever 738 harm the attacker intends at the subverted Diameter node itself. The 739 advantage of using ER to accomplish either of the attacks is that it 740 makes it more difficult to determine which node misbehaved, but the 741 extra effort involved to implement the attack does not seem to be 742 worth the potential gain. 744 8. Acknowledgements 746 The authors gratefully acknowledge the contributions of: Tony Zhang, 747 Fortune Huang, Rajith R., Victor Fajardo, Jouni Korhonen, Tolga 748 Asveren, Mark Jones, Avi Lior, Steve Norreys, Lionel Morand, Dave 749 Frascone and Hannes Tschofenig. 751 9. References 753 9.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 759 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 761 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, 762 "Clarifications on the Routing of Diameter Requests Based 763 on the Username and the Realm", RFC 5729, December 2009. 765 9.2. Informative References 767 [TS23.234] 768 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 769 interworking; System description", TS 23.234 Version 770 7.4.0, 2006. 772 Authors' Addresses 774 Tina Tsou 775 Huawei Technologies 776 Bantian, Longgang District 777 Shenzhen 518129 778 P.R. China 780 Email: tena@huawei.com 782 Glen Zorn 783 Network Zen 784 1310 East Thomas Street 785 #306 786 Seattle, Washington 98102 787 USA 789 Phone: +1 (206) 377-9035 790 Email: gwz@net-zen.net 792 Tom Taylor (editor) 793 Huawei Technologies 794 1852 Lorraine Ave 795 Ottawa 796 Canada 798 Email: tom111.taylor@bell.net