From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6159.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc6159.txt (limited to 'doc/rfc/rfc6159.txt') diff --git a/doc/rfc/rfc6159.txt b/doc/rfc/rfc6159.txt new file mode 100644 index 0000000..d05b486 --- /dev/null +++ b/doc/rfc/rfc6159.txt @@ -0,0 +1,1067 @@ + + + + + + +Independent Submission T. Tsou +Request for Comments: 6159 Huawei Technologies (USA) +Category: Informational G. Zorn +ISSN: 2070-1721 Network Zen + T. Taylor, Ed. + Huawei Technologies + April 2011 + + + Session-Specific Explicit Diameter Request Routing + +Abstract + + This document describes a mechanism to enable specific Diameter + proxies to remain in the path of all message exchanges constituting a + Diameter session. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6159. + +IESG Note + + Techniques similar to those discussed in this document were discussed + in the IETF Diameter Maintenance and Extensions (DIME) Working Group. + The group had no consensus that the problems addressed by such work + are a real concern in Diameter deployments. Furthermore, there was + no consensus that the proposed solutions are in line with the + architectural principles of the Diameter protocol. As a result, the + working group decided not to undertake the work. There has also not + been a formal request for this functionality from any standards body. + This RFC represents a continuation of the abandoned work. Readers of + this specification should be aware that the IETF has not reviewed + this specification and cannot say anything about suitability for a + particular purpose or compatibility with the Diameter architecture + and other extensions. + + + +Tsou, et al. Informational [Page 1] + +RFC 6159 Diameter Explicit Routing April 2011 + + +Copyright Notice + + Copyright (c) 2011 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. The 3GPP Wireless LAN (WLAN) Access Architecture ................4 + 3.1. Maintaining the Routing Path ...............................5 + 4. Diameter Explicit Routing (ER) ..................................6 + 4.1. Originating a Request (ER-Originator) ......................6 + 4.2. Relaying and Proxying Requests (ER-Proxy) ..................8 + 4.3. Receiving Requests (ER-Destination) .......................10 + 4.4. Diameter Answer Processing ................................11 + 4.5. Failover and Failback Considerations ......................12 + 4.6. Attribute-Value Pairs .....................................12 + 4.6.1. Explicit-Path-Record AVP ...........................12 + 4.6.1.1. Proxy-Host AVP ............................13 + 4.6.1.2. Proxy-Realm AVP ...........................13 + 4.6.2. Explicit-Path AVP ..................................13 + 4.7. Error Handling ............................................13 + 5. Example Message Flow ...........................................14 + 6. RADIUS/Diameter Protocol Interactions ..........................16 + 7. Security Considerations ........................................17 + 8. Acknowledgements ...............................................17 + 9. References .....................................................18 + 9.1. Normative References ......................................18 + 9.2. Informative References ....................................18 + +1. Introduction + + In the Diameter base protocol [RFC3588], the routing of request + messages is based solely on the routing decisions made separately by + each node along the path. [RFC5729] has added the ability to force + messages to pass through a specified set of realms through the use of + Network Access Identifier (NAI) decoration. However, no other + specification provides the ability to force routing through a + specific set of agents. Therefore, in a topology where multiple + paths exist from source to destination, there is no guarantee that + + + +Tsou, et al. Informational [Page 2] + +RFC 6159 Diameter Explicit Routing April 2011 + + + all messages relating to a given session will take the same path. In + general, this has not caused problems, but some architectures (e.g., + WLAN Third Generation Partnership Project (3GPP) IP access + [TS23.234]) require that once certain agents become engaged in a + session, they be able to process all subsequent messages for that + session. + + While the solution presented in this document is valid, it violates + one of the basic premises of Diameter -- the robustness of its + architecture. With normal Diameter routing, sessions will survive + failures of agents along the routing path. With the proposals in + this document, routing becomes pinned to specific agents whose + failure will terminate the session. + + The authors see no interaction between explicit routing and the + specific applications with which it is employed. Hence, in principle + it can be added to existing applications if they support the + necessary extensibility, and equally can be used with new + applications. + +2. Terminology + + 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 [RFC2119]. + + The following terms are used to define the functionality and + participants in the routing extensions described in this document. + + ER + Explicit routing -- the mechanism provided by this specification + to allow proxies traversed by the initial message of a session to + ensure that they remain on the messaging path for all subsequent + request messages of a session. + + ER-Proxy + A proxy that implements the ER mechanism and can therefore use it + to remain in the path for subsequent messages of a session. + + ER-Destination + A Diameter node that is capable of participating in ER and that + will ultimately consume the request sent by an ER-Originator. + + ER-Originator + A Diameter node initiating a session and sending the requests. + The ER-Originator can be any Diameter node sending a request, + i.e., a client, server or proxy capable of initiating sessions and + participating in ER. + + + +Tsou, et al. Informational [Page 3] + +RFC 6159 Diameter Explicit Routing April 2011 + + + Authentication, Authorization, and Accounting (AAA) Relays + Other Diameter nodes interspersed between the ER-Originator, + ER-Proxies, and the ER-Destination. These nodes represent + existing Diameter agents and proxies that do not participate in ER + and do not recognize Explicit-Path Attribute Value Pairs (AVPs). + +3. The 3GPP Wireless LAN (WLAN) Access Architecture + + The 3GPP WLAN IP access architecture [TS23.234] is one example of a + system requiring that certain agents (stateful proxies, in this case) + remain in the forwarding path of all session messages. The 3GPP WLAN + interworking architecture extends 3GPP services to the WLAN access + side, enabling a 3GPP subscriber to use a WLAN to access 3GPP + services. + + WLAN AAA provides access to the WLAN to be authenticated and + authorized through the 3GPP system. This access control can permit + or deny a subscriber access to the WLAN system and/or the 3GPP + system. + + There are two 3GPP WLAN interworking reference models: + + 1. In the non-roaming case, the model includes the WLAN access + network and the 3GPP AAA server in the home network. The 3GPP + AAA server is responsible for access control as well as charging. + + 2. In the roaming case, the model includes the WLAN access network, + the 3GPP AAA proxy in the visited network, and the 3GPP AAA + server in the home network. The 3GPP AAA server is responsible + for access control. Charging records may be generated by the AAA + proxy and/or the AAA server. The AAA proxy relays access control + and charging messages to the AAA server. The AAA proxy will also + do offline charging, if required. + + The roaming case presents two problems for which the Diameter routing + mechanism described in [RFC3588] does not offer any unambiguous and + standard solution. + + Network Selection + Selecting an initial message path for the Diameter session through + (possibly many) alternative visited network(s) to the home + network. + + Explicit Routing (ER) + Maintaining the selected message path for all messages in the + Diameter session. + + + + + +Tsou, et al. Informational [Page 4] + +RFC 6159 Diameter Explicit Routing April 2011 + + + Selecting an initial message path is outside the scope of this + document. A mechanism for maintaining the selected message path is + described in detail below. + +3.1. Maintaining the Routing Path + + After a successful authentication, a Diameter session is established + involving (at least) the following stateful entities: + + o the Diameter client in the WLAN access node (e.g., the 3GPP AAA + client in the terminal visited network), + + o a Diameter proxy in the visited mobile network (e.g., the 3GPP AAA + proxy in the terminal visited network), and + + o a Diameter server in the user's home realm (e.g., the destination + 3GPP AAA server in the terminal home network). + + Message routing for the initial session request uses the normal + Diameter routing tables (Section 2.7 of [RFC3588]) in the 3GPP AAA + client, the 3GPP AAA proxy in the visited network, and any + intermediate proxies after that. The 3GPP AAA client sends the + initial session request to the 3GPP AAA proxy in the visited network. + The 3GPP AAA proxy processes the request, then forwards it towards + the destination 3GPP AAA server, through an intermediate proxy if + necessary. The request may be forwarded through other intermediate + proxies in the same way, until it reaches the destination 3GPP AAA + server in the terminal home network. + + The functions assigned to the 3GPP AAA proxy include: + + o Reporting charging information to the offline charging system in + the visited network, + + o Policy enforcement based on roaming agreements, and + + o Service termination initiated by the visited network's operator. + + These functions all require that state be maintained within the + visited network. The 3GPP's choice is to maintain that state at the + 3GPP AAA proxy. This means that the latter must remain in the + messaging path for all subsequent messages relating to the same + session. + + + + + + + + +Tsou, et al. Informational [Page 5] + +RFC 6159 Diameter Explicit Routing April 2011 + + +4. Diameter Explicit Routing (ER) + + This section outlines a Diameter ER mechanism by which Diameter nodes + participating in ER can remain in the path of all request messages + for a specific session. A new Explicit-Path AVP is defined to enable + ER participants to manipulate the Destination-Host and/or + Destination-Realm AVPs of request messages in order to ensure the + correct routing behavior. The following sections describe the + extensions to the request routing in [RFC3588] to implement the ER + mechanism. The proposed extensions utilize existing routing + strategies in [RFC3588] and do not mandate modifications to it. The + mechanism imposes loose rather than strict source routing, in that + subsequent messages of a session are forced through the participating + nodes, but not through any individual non-participating nodes. In + summary, only Diameter nodes interested in participating in the ER + scheme will be involved in it. + +4.1. Originating a Request (ER-Originator) + + A Diameter node acting as an ER-Originator for a particular session + MUST maintain a local cache that enumerates all the Diameter + identities of the ER-Proxies that the request messages must traverse + along the path to the ER-Destination. The identity of a Diameter + node is defined in [RFC3588]. The local cache MAY also include the + node's realm. The data structure of the cache is left up to the + implementation and SHOULD persist as part of the session attributes + or properties. + + An ER-Originator sending request messages MUST add an Explicit-Path + AVP to these requests. The contents of the cache SHOULD be used to + populate the Explicit-Path AVP, with each cached entry represented by + a corresponding instance of the Explicit-Path-Record AVP. ER-Proxies + along the path of the request message MUST examine the contents of + the Explicit-Path AVP and make routing adjustments based on records + it contains. An example of the message flow is shown in Section 5. + Note that the ER-Originator can be any Diameter node, i.e., a client, + server, or proxy. + + The ER-Originator can populate the cache either by pre-configuring + its contents or by using the first request message of the session to + gather identities of participating ER-Proxies along the routing path. + The latter scheme is known as Explicit-Path discovery. The contents + of the cache can be pre-configured if the ER-Originator has explicit + knowledge of the ER-Proxies the request messages must traverse; + otherwise, the ER-Originator can use Explicit-Path discovery. It is + RECOMMENDED that Explicit-Path discovery be used whenever possible + since pre-configuration is less flexible by nature. + + + + +Tsou, et al. Informational [Page 6] + +RFC 6159 Diameter Explicit Routing April 2011 + + + Explicit-Path discovery is useful if the identities of the ER-Proxies + are not known or if there are several ER-capable proxies (a cluster + of proxies) that can be dynamically chosen based on other routing + policies. In Explicit-Path discovery, the cache of the ER-Originator + is initially empty. To initiate discovery, when the ER-Originator + sends the first request message of a session, it MUST include the + Explicit-Path AVP containing a single Explicit-Path-Record AVP with + the identity and/or the realm of the ER-Originator. The + ER-Originator MUST set the Destination-Host and/or Destination-Realm + AVP of the request message to the identity and/or the realm of the + ER-Destination, respectively, as specified in [RFC3588]. + + Note that ER-Originator initial request message routing procedures + and the process of population of the Destination-Realm may be + affected by the User-Name AVP NAI decoration [RFC5729]. NAI + decoration is a form of request message source routing and defines + realms that the request message must traverse through before + routing towards the ER-Destination. Diameter nodes participating + in request message routing must examine and process the User-Name + AVP, and modify the Destination-Realm AVP accordingly as long as + there are realms left in the decorated NAI. Source routing based + upon NAI decoration does not affect Explicit-Path discovery as + defined in this document. + + If the path taken by the initial request encounters one or more + participating ER-Proxies and a participating ER-Destination, the + procedures described in Section 4.2 and Section 4.3 ensure that a + successful response to that request will contain an Explicit-Path AVP + that includes one or more Explicit-Path-Records containing the + ER-Originator's identity, the identities of all participating + ER-Proxies, and the identity of the ER-Destination. The + ER-Originator SHOULD populate its local cache with the contents of + the Explicit-Path AVP received in this initial answer message. + + If the answer message does not contain an Explicit-Path AVP or the + Result-Code AVP is set to DIAMETER_ER_NOT_AVAILABLE (Section 4.7), it + is an indication to the ER-Originator that the destination of the + request does not support ER and that the ER-Originator SHOULD avoid + sending an Explicit-Path AVP in subsequent request messages. + + If the initial request message initiated Explicit-Path discovery, but + the Explicit-Path AVP in the answer message contains Explicit-Path- + Records for the ER-Originator and ER-Destination only, it is an + indication to the ER-Originator that there are no Diameter proxies + capable of participating in ER along the path and that the + ER-Originator SHOULD NOT send an Explicit-Path AVP in subsequent + request messages of this session. See Section 4.5 for more + discussion. In such cases, the situation may be transient, and + + + +Tsou, et al. Informational [Page 7] + +RFC 6159 Diameter Explicit Routing April 2011 + + + Explicit-Path discovery may find participating proxies in succeeding + sessions. It is left up to the ER-Originator to decide if Explicit- + Path discovery should be attempted in succeeding sessions. + + Once the ER-Originator's local cache has been populated, whether by + pre-configuration or through Explicit-Path discovery, all request + messages for the session MUST include the Explicit-Path AVP using the + contents of the local cache. The Explicit-Path AVP MUST contain the + Explicit-Path-Records of all the nodes enumerated in the cache except + that of the ER-Originator itself. The identities enumerated in the + Explicit-Path AVP MUST appear in the order they will be traversed in + the routing path. The last entry in the Explicit-Path AVP MUST be + the Explicit-Path-Record of the ER-Destination. In addition, the + value of the Destination-Host and possibly the Destination-Realm in + the request message MUST be copied from the values of the Proxy-Host + AVP and, if present, the Proxy-Realm AVP of the first Explicit-Path- + Record AVP present in the Explicit-Path AVP. + + This ensures that the ER-Originator as well as any AAA relays + between the ER-Originator and the first ER-Proxy will route the + message towards the first ER-Proxy as specified in RFC 3588 + [RFC3588]. + + Subsequent actions taken by the first ER-Proxy upon receipt of the + message are described in Section 4.2 and will mimic those of the + ER-Originator. + + Answer messages received by the ER-Originator to subsequent request + messages after the Explicit-Path has been established SHOULD NOT have + an Explicit-Path AVP. If they do, this SHOULD be considered a + suspect condition that may be caused by a misbehaving ER participant. + It is left up to the ER-Originator whether to continue using the ER + scheme when such a condition arises or to attempt another Explicit- + Path discovery for subsequent sessions. + +4.2. Relaying and Proxying Requests (ER-Proxy) + + The basic action taken by an ER-Proxy upon receiving a request is to + check whether explicit routing is supported in the request and if so, + check whether it is already a participant in explicit routing for the + said request. If it is not an existing participant, if Explicit-Path + discovery is in progress, and if it wishes to participate, it appends + an Explicit-Path-Record AVP identifying itself to the end of the + Explicit-Path AVP. If it is an existing participant, the ER-Proxy + pops/removes the Explicit-Path-Record AVP pertaining to itself from + the Explicit-Path AVP and then uses the next Explicit-Path-Record AVP + for subsequent routing. Details of this operation follow. + + + + +Tsou, et al. Informational [Page 8] + +RFC 6159 Diameter Explicit Routing April 2011 + + + An ER-Proxy is not required to keep local state or cache state + regarding the explicit routing procedure. However, it MUST check + whether an incoming request contains an Explicit-Path AVP. The + following cases can occur. + + 1. If an incoming request does not contain an Explicit-Path AVP, + then the ER-Proxy takes no action beyond processing and + forwarding the request as specified in [RFC3588]. + + 2. If the incoming request contains an Explicit-Path AVP, the + ER-Proxy MUST check whether its identity is present in the + Explicit-Path AVP. Determining whether its identity is present + can be done by matching its identity to the Proxy-Host AVP + contained in each Explicit-Path-Record. If its identity is not + present, then: + + A. If it wishes to participate in explicit routing, the ER-Proxy + MUST verify that Explicit-Path discovery is in progress by + verifying that the Proxy-Host AVP in the first Explicit-Path- + Record AVP in the Explicit-Path AVP does not match the + Destination-Host AVP (if present). If this verification + succeeds or the Destination-Host AVP is absent, the ER-Proxy + MAY append a new Explicit-Path-Record as the last AVP in the + Explicit-Path AVP prior to forwarding the request. The new + Explicit-Path-Record MUST contain a Proxy-Host AVP set to the + proxy's identity, and MAY contain a Proxy-Realm AVP giving + the proxy's realm. If, however, the Destination-Host AVP is + present and matches the Proxy-Host AVP of the first Explicit- + Path-Record AVP, then the Explicit-Path contains an already- + defined source route that does not include the ER-Proxy. The + ER-Proxy SHOULD process the request as if the ER-Path AVP + were absent. + + B. If the ER-Proxy does not wish to participate in the ER, it + SHOULD NOT modify the Explicit-Path AVP and SHOULD simply + process and forward the request as specified in [RFC3588] + using the existing values of the Destination-Host and/or + Destination-Realm AVPs. Non-ER-Proxies and relays that do + not support ER and do not recognize Explicit-Path AVP will + take the same action. + + + + + + + + + + + +Tsou, et al. Informational [Page 9] + +RFC 6159 Diameter Explicit Routing April 2011 + + + 3. If the identity of the ER-Proxy is present in the Explicit-Path + AVP, then: + + A. If it is not the first Explicit-Path-Record in the AVP, this + MUST be considered an error, and an answer message with the + 'E' bit set and the Result-Code set to + DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the + ER-Originator (Section 4.7). + + B. If the identity of the ER-Proxy matches the first Explicit- + Path-Record, the ER-Proxy MUST remove this record from the + Explicit-Path AVP and repopulate the Destination-Host and + possibly the Destination-Realm AVP from the next Explicit- + Path-Record present in the Explicit-Path AVP. Setting the + Destination-Host and possibly the Destination-Realm AVP will + ensure that the ER-Proxy as well as all AAA relays between + the current ER-Proxy and the next ER-Proxy enumerated in the + Explicit-Path AVP will route the message towards the next + ER-Proxy. The process of removing the ER-Proxy's record is + analogous to popping an entry from a stack represented by the + Explicit-Path AVP. + + The behavior specified above also applies to a Diameter node that + acts as a relay agent and participates in the ER scheme. + +4.3. Receiving Requests (ER-Destination) + + A Diameter node that locally processes requests sent by the + ER-Originator (Section 4.1) and is able to support ER (an + ER-Destination) MUST check for the presence of an Explicit-Path AVP + in the request message. + + 1. If an incoming request does not contain an Explicit-Path AVP, + then it is an indication that messages belonging to this session + will not use ER. The ER-Destination MUST simply process the + request for local consumption and formulate an answer message as + specified in [RFC3588]. + + + + + + + + + + + + + + +Tsou, et al. Informational [Page 10] + +RFC 6159 Diameter Explicit Routing April 2011 + + + 2. If the incoming request contains an Explicit-Path AVP, the + ER-Destination MUST check whether its identity is present in the + Explicit-Path AVP. If its identity is not present, indicating + that Explicit-Path discovery is in progress, then: + + A. If it wishes to participate in the ER, and subject to + paragraph B below, the ER-Destination MUST append a new + Explicit-Path-Record to the Explicit-Path AVP in the received + message. The new Explicit-Path-Record MUST contain at the + least a Proxy-Host AVP set to the ER-Destination's identity. + The ER-Destination MUST then copy the resulting Explicit-Path + AVP to the subsequent answer message. + + B. If there is only one Explicit-Path-Record in the incoming + Explicit-Path AVP, then this is an indication of a successful + Explicit-Path discovery, but with no participating + ER-Proxies. The ER-Destination SHOULD NOT copy the Explicit- + Path AVP into the subsequent answer message. + + C. If the ER-Destination supports ER but does not wish to or + cannot participate, it MAY send a Result-Code AVP set to + DIAMETER_ER_NOT_AVAILABLE as defined in Section 4.7. The + ER-Destination MUST NOT include any Explicit-Path AVP in the + subsequent answer. Diameter servers that do not support ER + and do not recognize the Explicit-Path AVP will also omit the + Explicit-Path AVP from the answer message. + + 3. If the identity of the ER-Destination matches a record in the + Explicit-Path AVP, then it MUST be the only Explicit-Path-Record + present in the Explicit-Path AVP. Otherwise, this MUST be + considered an error, and an answer message with the 'E' bit set + and containing an Experimental-Result-Code AVP set to + DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the + ER-Originator (Section 4.7). If the identity of the + ER-Destination does match the only existing Explicit-Path-Record, + then this is an indication that the request reached the + ER-Destination by way of a successfully executed explicit route. + The ER-Destination MUST NOT include the Explicit-Path AVP in the + subsequent answer message. + +4.4. Diameter Answer Processing + + There is no requirement on Diameter nodes participating in ER to + provide special handling or routing of answer messages. Answer + messages SHOULD be processed normally as specified in [RFC3588]. + However, a Diameter node acting as an ER-Destination MUST formulate a + proper Explicit-Path AVP in answer messages as described in + Section 4.3. + + + +Tsou, et al. Informational [Page 11] + +RFC 6159 Diameter Explicit Routing April 2011 + + +4.5. Failover and Failback Considerations + + If there is no ER-Proxy along the selected path, the answer message + MAY contain an Explicit-Path AVP that contains only the Explicit- + Route-Records of the ER-Originator and the ER-Destination, indicating + that there is no ER support found in Diameter nodes along the path. + It is left to the ER-Originator to continue with processing of the + request without ER support or terminate the session. The + ER-Originator SHOULD NOT attempt to perform Explicit-Path discovery + in subsequent request messages of this session in such cases, to + protect against failback conditions where an ER-Proxy suddenly + appears in the path and attempts to add a new Explicit-Path-Record + for request messages other than the initial request. + + Allowing an ER-Proxy to join the session after the initial request + makes sense only if the application requirements do not mandate + that every participating ER-Proxy receive all of the messages of a + session. + + However, depending on local policy, the ER-Originator MAY attempt ER + path discovery in subsequent sessions despite the lack of proxy + participants in the earlier attempt. + + If a failover occurs in a Diameter node preceding an ER-Proxy when + the Explicit-Path is already established, it is possible that a + DIAMETER_UNABLE_TO_DELIVER error will be received by the + ER-Originator if there are no alternative paths towards the ER-Proxy. + In such a case, it is left to the ER-Originator to handle the error + as specified in the Diameter application or in [RFC3588]. + +4.6. Attribute-Value Pairs + + The following sections define the AVPs used in the ER process. All + of these AVPs MUST have the 'V' bit set and the 'M' bit cleared, with + the Vendor-ID field set to 2011 (as assigned by IANA in "Private + Enterprise Numbers" registry; see http://www.iana.org/). + +4.6.1. Explicit-Path-Record AVP + + The Explicit-Path-Record AVP (AVP Code 35001) is of type Group. The + identity added in the Proxy-Host [RFC3588] element of this AVP MUST + be the same as the one advertised by the Diameter node in the Origin- + Host AVP during the Capabilities Exchange messages. + + Explicit-Path-Record ::= < AVP Header: 35001 > + { Proxy-Host } + [ Proxy-Realm ] + + + + +Tsou, et al. Informational [Page 12] + +RFC 6159 Diameter Explicit Routing April 2011 + + +4.6.1.1. Proxy-Host AVP + + The Proxy-Host AVP (AVP Code 35004) is of type DiameterIdentity. It + identifies the ER node that is inserting the record. The Proxy-Host + AVP MUST be present. + +4.6.1.2. Proxy-Realm AVP + + The Proxy-Realm AVP (AVP Code 35002) is of type DiameterIdentity, and + contains the realm of the ER node inserting the record. The Proxy- + Realm AVP MAY be present in the Explicit-Path-Record. If it is + present, the realm name included in the value of the Proxy-Host AVP + MUST match the value of the Proxy-Realm AVP. + +4.6.2. Explicit-Path AVP + + The Explicit-Path AVP (AVP Code 35003) is of type Grouped. This AVP + MUST be present in all request messages performing ER. It MAY be + present in the answer to the initial session request message if + Explicit-Path discovery was successfully executed for the request. + + Explicit-Path ::= < AVP Header: 35003 > + 1* [ Explicit-Path-Record ] + * [ AVP ] + +4.7. Error Handling + + The following error conditions may occur during ER processing. All + error indications MUST be encapsulated in an instance of the + Experimental-Result AVP [RFC3588] with the Vendor-ID AVP set to 2011 + and the Experimental-Result-Code set as specified below. + + DIAMETER_INVALID_PROXY_PATH_STACK 3501 + + A request message received by an ER-Proxy or ER-Destination after + an Explicit-Path has been established has the first or only + Explicit-Path-Record AVP not matching the ER-Proxy's or the + ER-Destination's identity. The same error applies to + ER-Destinations receiving an Explicit-Path-AVP containing more + than one Explicit-Path-Record or an Explicit-Path-AVP with only + one Explicit-Path-Record not matching its own identity. + + This error SHOULD be considered a protocol failure and SHOULD be + treated on a per-hop basis; Diameter proxies may attempt to + correct the error, if possible. Diameter answer messages + containing this error indication MUST have the 'E' bit set and + MUST conform to Section 7.2 of [RFC3588]. + + + + +Tsou, et al. Informational [Page 13] + +RFC 6159 Diameter Explicit Routing April 2011 + + + DIAMETER_ER_NOT_AVAILABLE 4501 + + An ER-Destination that supports ER routing but is unable to comply + for unknown reasons MAY send an answer message with the Result- + Code AVP set to this error code. This error value SHOULD be + considered a transient failure indicating that subsequent ER + attempts may succeed. + +5. Example Message Flow + + The example presented here illustrates the flow of Diameter messages + with the typical attributes present in the ER scenario. + + The ER-Originator in the example below shows the use of Explicit-Path + discovery with the first request. However, the ER-Originator could + also use a pre-configured cache. The ER-Originator can be any + Diameter node sending a request, i.e., a client, server, or proxy. + In this scenario, the local cache of the ER-Originator is initially + empty. + + The AAA relays between the ER-Proxies, ER-Originator, and + ER-Destination may or may not be present and are shown here to depict + routing paths that the requests may take prior to being processed by + nodes participating in the ER scheme. The AAA relays also depict + existing Diameter relays or proxies that do not recognize Explicit- + Path AVPs and therefore do not participate in ER. + + + + + + + + + + + + + + + + + + + + + + + + + +Tsou, et al. Informational [Page 14] + +RFC 6159 Diameter Explicit Routing April 2011 + + + ER- ER- ER- ER- + Originator AAA relays Proxy1 AAA relays Proxy2 Destination + (o.r1 (p.r1 (p.r2 (d.r2 + .example) .example) .example) .example) + | | | | | + cache=(empty) | | | | | + ------------->|--------->| | | | + (1st request of the session)| | | | + Explicit-Path= | | | | + o.r1.example,r1.example | | | + dest-host=d.r2.example | | | | + dest-realm=r2.example | | | | + | | | | | + | |--------->|--------->| | + | | (forwarded request)| | + | | Explicit-Path= | | + | | record1=o.r1.example,r1.example + | | record2=p.r1.example,r1.example + | | dest-host=d.r2.example | + | | dest-realm=r2.example | + | | | | | + | | | |--------->| + | | | (forwarded request) + | | | Explicit-Path= + | | | record1=o.r1.example, + | | | r1.example + | | | record2=p.r1.example, + | | | r1.example + | | | record3=p.r2.example, + | | | r2.example + | | | dest-host=d.r2.example + | | | dest-realm=r2.example + | | | | | + cache= |<---------|<---------|<---------|<---------| + record1=o.r1.example,r1.example (answer) | + record2=p.r1.example,r1.example Explicit-Path= + record3=p.r2.example,r2.example record1=o.r1.example,r1.example + record4=d.r2.example,r2.example record2=p.r1.example,r1.example + | | record3=p.r2.example,r2.example + | | record4=d.r2.example,r2.example + Note: An originator pre-configuring | | | + its local cache can skip the | | | + exchange above and send the | | | + initial request as shown below. | | | + + + + + + + +Tsou, et al. Informational [Page 15] + +RFC 6159 Diameter Explicit Routing April 2011 + + + | | | | | + ------------->|--------->| | | | + (subsequent request of the session) | | | + Explicit-Path= | | | | + record1=p.r1.example,r1.example | | | + record2=p.r2.example,r2.example | | | + record3=d.r2.example,r2.example | | | + dest-host=p.r1.example | | | | + dest-realm=r1.example | | | | + | |--------->|--------->| | + | | (forwarded request)| | + | | Explicit-Path= | | + | | record1=p.r2.example,r2.example + | | record2=d.r2.example,r2.example + | | dest-host=p.r2.example | + | | dest-realm=r2.example | + | | | | | + | | | |--------->| + | | | (forwarded request) + | | | Explicit-Path + | | | record1=d.r2.example, + | | | r2.example + | | | dest-host=d.r2.example + | | | dest-realm=r2.example + | | | | | + cache= |<---------|<---------|<---------|<---------| + record1=o.r1.example,r1.example (answer) | | + record2=p.r1.example,r1.example * no Explicit-Path-AVP present + record3=p.r2.example,r2.example | | | + record4=d.r2.example,r2.example | | | + | | | | | + | | | | | + (subsequent request of the session will repeat the process above) + | | | | | + | | | | | + + Figure 1: Example ER Message Flow + +6. RADIUS/Diameter Protocol Interactions + + No actions need to be taken with regards to RADIUS/Diameter + interaction. The routing extension described in this document is + transparent to any translation gateway and relevant only to Diameter + routing. The assumption is that if there is a RADIUS proxy chain + between Diameter translation agents, the route between translation + agents remains stable during the session and does not cause an + invalidation of the proxy path stack. + + + + +Tsou, et al. Informational [Page 16] + +RFC 6159 Diameter Explicit Routing April 2011 + + +7. Security Considerations + + The security considerations in [RFC3588] apply to this extension. In + addition, this extension raises questions of authorization and can + potentially allow a new denial-of-service attack. + + The authorization issue comes about because the proxies that + participate in ER are self-selected. An ER-Proxy is able, through + the operation of ER, to guarantee that it can monitor every message + of a session. This is in contrast to ordinary Diameter routing, + where some messages may pass by an alternate route. The question is + whether the originating party is prepared to extend this additional + degree of trust to arbitrary parties along the path. If not, the + ER-Originator requires a mechanism to determine whether an ER-Proxy + listed in the returned Explicit-Path AVP can be trusted. If it has + such a mechanism, then an unwanted ER-Proxy can be deleted from its + cache and thus not appear in the ER-Path AVP in subsequent requests. + This specification assumes that either the originating party is + prepared to allow arbitrary Diameter nodes along the path to attach + themselves to the session as ER-Proxies, or the ER-Originator + maintains a pre-configured list of ER-Proxies in its cache. + + The potential denial-of-service attack is not a serious one because + the same result can be obtained more directly. An attacker with + control of a Diameter node along the path of the original request + could insert an Explicit-Path-Record containing the identity of + another node or a non-existent node, rather than its own identity. + Routing subsequent messages of the session through another node could + result in violation of the trust assumptions made upstream. Routing + subsequent messages to a non-existent node causes them to be lost and + terminates the session. It would seem simpler to perpetrate whatever + harm the attacker intends at the subverted Diameter node itself. The + advantage of using ER to accomplish either of the attacks is that it + makes it more difficult to determine which node misbehaved, but the + extra effort involved to implement the attack does not seem to be + worth the potential gain. + +8. Acknowledgements + + The authors gratefully acknowledge the contributions of Tony Zhang, + Fortune Huang, Rajith R., Victor Fajardo, Jouni Korhonen, Tolga + Asveren, Mark Jones, Avi Lior, Steve Norreys, Lionel Morand, Dave + Frascone, and Hannes Tschofenig. + + + + + + + + +Tsou, et al. Informational [Page 17] + +RFC 6159 Diameter Explicit Routing April 2011 + + +9. References + +9.1. 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. + + [RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou, + "Clarifications on the Routing of Diameter Requests Based + on the Username and the Realm", RFC 5729, December 2009. + +9.2. Informative References + + [TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) + interworking; System description", TS 23.234 + Version 7.4.0, 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tsou, et al. Informational [Page 18] + +RFC 6159 Diameter Explicit Routing April 2011 + + +Authors' Addresses + + Tina Tsou + Huawei Technologies (USA) + 2330 Central Expressway + Santa Clara, CA 95050 + USA + + Phone: +1 408 330 4424 + EMail: tena@huawei.com + URI: http://tinatsou.weebly.com/contact.html + + + Glen Zorn + Network Zen + 227/358 Thanon Sanphawut + Bang Na, Bangkok 10260 + Thailand + + Phone: +66 (0) 87-040-4617 + EMail: gwz@net-zen.net + + + Tom Taylor (editor) + Huawei Technologies + 1852 Lorraine Ave. + Ottawa + Canada + + EMail: tom111.taylor@bell.net + + + + + + + + + + + + + + + + + + + + + +Tsou, et al. Informational [Page 19] + -- cgit v1.2.3