GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6159

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6159.txt · Last modified: 2011/04/14 17:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki