Skip to main content

Session-Specific Explicit Diameter Request Routing
draft-tsou-diameter-explicit-routing-05

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6159.
Authors Tina Tsou (Ting ZOU) , Glen Zorn , Tom Taylor
Last updated 2015-10-14 (Latest revision 2010-06-21)
RFC stream Independent Submission
Intended RFC status Informational
Formats
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 6159 (Informational)
Action Holders
(None)
Telechat date (None)
Responsible AD Dan Romascanu
Send notices to (None)
draft-tsou-diameter-explicit-routing-05
Network Working Group                                            T. Tsou
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                   G. Zorn
Expires: December 24, 2010                                   Network Zen
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                           June 22, 2010

           Session-Specific Explicit Diameter Request Routing
                draft-tsou-diameter-explicit-routing-05

Abstract

   This document describes a mechanism to enable specific Diameter
   proxies to remain in the path of all message exchanges constituting a
   Diameter session.  This document is being published to provide the
   basis for a standardized solution to a problem raised by some
   architectures (e.g., WLAN 3GPP IP access, 3GPP TS23.234) that use
   Diameter.  The intended use will be as a reference within the non-
   IETF specification of a Diameter application that meets the needs of
   these architectures.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 24, 2010.

Copyright Notice

   Copyright (c) 2010 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

Tsou, et al.            Expires December 24, 2010               [Page 1]
Internet-Draft          Diameter Explicit Routing              June 2010

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Tsou, et al.            Expires December 24, 2010               [Page 2]
Internet-Draft          Diameter Explicit Routing              June 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The 3GPP Wireless LAN (WLAN) Access Architecture . . . . . . .  5
     3.1.  Maintaining the Routing Path . . . . . . . . . . . . . . .  6
   4.  Diameter Explicit Routing (ER) . . . . . . . . . . . . . . . .  6
     4.1.  Originating a request (ER-Originator)  . . . . . . . . . .  7
     4.2.  Relaying and Proxying Requests (ER-Proxy)  . . . . . . . .  9
     4.3.  Receiving Requests (ER-Destination)  . . . . . . . . . . . 11
     4.4.  Diameter answer processing . . . . . . . . . . . . . . . . 12
     4.5.  Failover and Failback Considerations . . . . . . . . . . . 12
     4.6.  Attribute-Value Pairs  . . . . . . . . . . . . . . . . . . 12
       4.6.1.  Explicit-Path-Record AVP . . . . . . . . . . . . . . . 13
         4.6.1.1.  Proxy-Realm AVP  . . . . . . . . . . . . . . . . . 13
       4.6.2.  Explicit-Path AVP  . . . . . . . . . . . . . . . . . . 13
     4.7.  Error Handling . . . . . . . . . . . . . . . . . . . . . . 13
     4.8.  Example Message Flow . . . . . . . . . . . . . . . . . . . 14
   5.  RADIUS/Diameter Protocol Interactions  . . . . . . . . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Tsou, et al.            Expires December 24, 2010               [Page 3]
Internet-Draft          Diameter Explicit Routing              June 2010

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
   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 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 3GPP IP access [TS23.234]) require
   that once certain agents become engaged in a session, they are 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 IETF does not endorse this
   specification because of its impact on Diameter session
   survivability, but do not object to its publication for use in
   specialized situations where the loss of robustness is acceptable.

   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.

Tsou, et al.            Expires December 24, 2010               [Page 4]
Internet-Draft          Diameter Explicit Routing              June 2010

   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 which is capable of participating in ER and which
      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. client, server or proxy capable of initiating sessions and
      participating in ER.

   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 AVPs.

3.  The 3GPP Wireless LAN (WLAN) Access Architecture

   One example of a system requiring that certain agents (stateful
   proxies, in this case) remain in the forwarding path of all session
   messages is the 3GPP WLAN IP access architecture [TS23.234].  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 the 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.

Tsou, et al.            Expires December 24, 2010               [Page 5]
Internet-Draft          Diameter Explicit Routing              June 2010

   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
      Maintaining the selected message path for all messages in the
      Diameter session.

   The former is outside the scope of this document; the latter 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,

   o  a Diameter proxy (the 3GPP AAA proxy) in the visited mobile
      network, and

   o  a Diameter server in the user's home realm.

   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

   o  Service termination initiated by the visited network operator

   These functions all require that state be maintained within the
   visited network.  The 3GPP 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.

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

Tsou, et al.            Expires December 24, 2010               [Page 6]
Internet-Draft          Diameter Explicit Routing              June 2010

   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
   scheme also differs from existing strict source routing schemes in
   which all hops in the path have to participate.  In the ER mechanism,
   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 which 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 where each cached entry is 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 4.8.  Note that the ER-Originator can be any Diameter node,
   i.e. 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 it can use Explicit-Path discovery.  It is recommended that
   Explicit-Path discovery be used whenever possible since pre-
   configuration is less flexible by nature.

   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.  When the ER-Originator sends the first request

Tsou, et al.            Expires December 24, 2010               [Page 7]
Internet-Draft          Diameter Explicit Routing              June 2010

   message of a session, the Explicit-Path AVP will contain only one
   Explicit-Path-Record AVP with the identity and/or the realm of the
   ER-Originator.  The Destination-Host and/or Destination-Realm AVP of
   the request message is set to the identity and/or the realm of the
   ER-Destination respectively as specified in [RFC3588].

      It should be noted that ER-Originator initial request message
      routing procedures and the population of 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
      to the 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 the Explicit-Path
      discovery as defined in this document.

   When the request message is received and processed by an ER-Proxy,
   the ER- Proxy MUST append a new Explicit-Path-Record containing its
   own identity and/or realm to the Explicit-Path AVP prior to
   forwarding the message.  Subsequent ER-Proxies along the path that
   wish to participate in the ER MUST also append their own Explicit-
   Path-Record in the same manner (Section 4.2).  When the request
   reaches the ER-Destination, it MUST append a new Explicit- Path-
   Record to the Explicit-Path AVP in a similar manner.  The ER-
   Destination MUST copy the resulting Explicit-Path AVP to the answer
   message (Section 4.3).  Once the answer message reaches the ER-
   Originator, the Explicit-Path AVP will contain 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, after performing Explicit-Path discovery, the Explicit-Path AVP
   in the answer message contains only the Explicit-Path-Record of the
   ER-Originator and ER-Destination then this SHOULD be 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

Tsou, et al.            Expires December 24, 2010               [Page 8]
Internet-Draft          Diameter Explicit Routing              June 2010

   situation may be transient and Explicit-Path discovery in succeeding
   sessions may find participating proxies.  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/or Destination-Realm AVP of the
   request messages MUST be set to the value of the Proxy-Host and/or
   Proxy- Realm 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 in
      between the ER-Originator and the first ER-Proxy will route the
      message towards the first ER-Proxy as specified in RFC3588
      [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 ER path has been established SHOULD NOT have an
   Explicit- Path AVP.  Otherwise, 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 on 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 an existing participant, the ER-Proxy MUST
   pop/remove the Explicit-Path-Record AVP pertaining to itself from the
   Explicit-Path AVP and then use the next Explicit-Path-Record AVP for
   subsequent routing.  Details of this operation are as follows.

   An ER-Proxy is not required to keep local state or cache state
   regarding the explicit routing procedure.  However, it MUST check

Tsou, et al.            Expires December 24, 2010               [Page 9]
Internet-Draft          Diameter Explicit Routing              June 2010

   whether an incoming request contains an Explicit- Path AVP.

   1.  If an incoming request does not contain an Explicit-Path AVP then
       the ER- Proxy MUST process and forward 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 AVPs contained in
       each Explicit-Path-Record.

       A.  If its identity is not present and it wishes to participate
           in explicit routing, the ER-Proxy MUST 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 at the least a Proxy-Host AVP set to the proxy's
           identity.  This scenario is part of the Explicit-Path
           discovery scheme described in Section 4.1.

       B.  However, if its identity is not present and the ER-Proxy does
           not wish to participate in the ER, it SHOULD NOT modify the
           Explicit-Path AVP and SHOULD simply forward the request as
           specified in [RFC3588] using the existing value of
           Destination-Host and/or Destination-Realm AVP.  Non ER-
           proxies and relays that do not support ER and do not
           recognize Explicit-Path AVP will take the same action.

       C.  If the identity of the ER-Proxy is present in the Explicit-
           Path AVP, then it MUST be the first Explicit-Path-Record in
           the AVP; otherwise, this SHOULD 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).  If the identity of the ER-
           Proxy matches the first Explicit-Path-Record, the ER-Proxy
           MUST remove this record from Explicit-Path AVP and set the
           Destination-Host and/or Destination-Realm AVP to the next
           Explicit-Path-Record present in the Explicit-Path AVP.
           Setting the Destination-Host and/or Destination-Realm AVP
           will ensure that the ER-Proxy as well as all AAA relays in
           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 removing an entry in a stack represented by
           the Explicit-Path AVP.

   Note that in the case of the ER-Destination, the Explicit-Path AVP
   MUST be empty once its own record is removed (Section 4.3).  Note

Tsou, et al.            Expires December 24, 2010              [Page 10]
Internet-Draft          Diameter Explicit Routing              June 2010

   also that the behavior specified above 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 Diameter node SHOULD process the request for
       local consumption and formulate an answer message as specified in
       [RFC3588].

   2.  If the incoming request contains an Explicit-Path AVP, the
       Diameter node MUST check whether its identity is present in the
       Explicit-Path AVP.

       A.  If its identity is not present in the Explicit-Path and it
           wishes to participate in the ER, the Diameter node 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.  This scenario is part of the proxy path discovery
           scheme described in Section 4.1.

       B.  If its identity is not present and 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 SHOULD NOT
           include any Explicit-Path AVP in the subsequent answer.  The
           same scenario applies to ER-destinations that do not support
           ER and do not recognize Explicit-Path AVP and is a hint to
           the ER-Originator that the destination does not support ER.

       C.  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
           SHOULD be considered an error and an answer message with the
           'E' bit set and containing an Experimental-Result-Code AVP
           with the set to Diameter_INVALID_PROXY_PATH_STACK MUST be
           sent back to the ER-Originator (Section 4.7).  If the
           identity of the of the ER-Destination matches the only
           existing Explicit-Path-Record, then this is an indication of

Tsou, et al.            Expires December 24, 2010              [Page 11]
Internet-Draft          Diameter Explicit Routing              June 2010

           a successful ER, but with no participating ER-Proxies.  The
           ER-Destination SHOULD NOT copy the Explicit-Path AVP into 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.

4.5.  Failover and Failback Considerations

   If there is no ER-Proxy along the selected path, the answer message
   will 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 so as 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
      is permissible only if the application requirements do not mandate
      that any participating ER-Proxy receive all of the messages of a
      session.

   However, based on local policy, the ER-Originator MAY attempt
   Explicit-Path discovery in subsequent sessions.

   If a failover occurs in a Diameter node preceding an ER-Proxy when
   the ER path is already established, it is possible that an
   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 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 in
   http://www.iana.org/assignments/enterprise-numbers).

Tsou, et al.            Expires December 24, 2010              [Page 12]
Internet-Draft          Diameter Explicit Routing              June 2010

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 ]

4.6.1.1.  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.

   It is recommended that the Proxy-Host AVP be present and used to
   uniquely identify an ER-Proxy within the AAA realm being traversed by
   a request.  Otherwise, ER will need to rely on realm routing.  Realm
   routing would require a well-known topology for the ER scheme to work
   properly since the hostname of the proxy is not specified.  In such a
   case, the Proxy-Realm AVP MUST be present and is used to identify the
   ER-Proxy of the realm.

   When a Proxy-Host AVP is present in the Explicit-Path-Record AVP, the
   realm name included in the hostname MUST correspond to the identity
   present in the Proxy-Realm AVP.

4.6.2.  Explicit-Path AVP

   The Explicit-Path AVP (AVP Code 35003) is of type Grouped.  This AVP
   SHOULD be present in all request and answer messages performing ER.

         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 ER path has been established has the first or only Explicit-
      Path-Record AVP not matching the ER-Proxy or the ER-Destinations

Tsou, et al.            Expires December 24, 2010              [Page 13]
Internet-Draft          Diameter Explicit Routing              June 2010

      identity.  The same error applies to ER-Destinations receiving a
      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].

   DIAMETER_ER_NOT_AVAILABLE                    4501
      An ER-Destination which 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.

4.8.  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 may
   also use a pre-configured cache.  The ER-Originator can be any
   Diameter node sending a request, i.e. client, server or proxy.  In
   this scenario, the local cache of the ER-Originator is initially
   empty.

   The AAA relays in 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.

       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     |          |          |          |

Tsou, et al.            Expires December 24, 2010              [Page 14]
Internet-Draft          Diameter Explicit Routing              June 2010

     dest-realm=r2.example      |          |          |          |
                     |          |          |          |          |
                     |          |--------->|--------->|          |
                     |          |  (forwarded request)|          |
                     |          |  Explicit-Path=     |          |
                     |          |    record1=o.r1.example,reaml1.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   |          |          |
                     |          |          |          |          |
       ------------->|--------->|          |          |          |
    (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        |

Tsou, et al.            Expires December 24, 2010              [Page 15]
Internet-Draft          Diameter Explicit Routing              June 2010

                     |          |  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

5.  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.

6.  IANA Considerations

   Because this document defines only vendor-specific AVPs and result
   codes, no IANA actions are necessary.

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

Tsou, et al.            Expires December 24, 2010              [Page 16]
Internet-Draft          Diameter Explicit Routing              June 2010

   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 the originating party is either
   prepared to allow arbitrary Diameter nodes along the path to attach
   themselves to the session as ER-Proxies, or else 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.

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.

Tsou, et al.            Expires December 24, 2010              [Page 17]
Internet-Draft          Diameter Explicit Routing              June 2010

   [RFC5729]  Korhonen, J., 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.

Authors' Addresses

   Tina Tsou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: tena@huawei.com

   Glen Zorn
   Network Zen
   1310 East Thomas Street
   #306
   Seattle, Washington  98102
   USA

   Phone: +1 (206) 377-9035
   Email: gwz@net-zen.net

   Tom Taylor (editor)
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa
   Canada

   Email: tom111.taylor@bell.net

Tsou, et al.            Expires December 24, 2010              [Page 18]