Subject: [AAA-WG]: [Issue] Fixes for Issue 50

From: Pat Calhoun <[email-masked]>
Date: Tue, 29 May 2001 18:20:37 -0700

All,

Today I posted my partial fix for Issue 50, and this is the complete
text. What I've done, in addition to the text I sent today, is pulled
all of the routing section into section 5, and cleaned it up considerably.

I am sending the fix I sent today since I changed the last sentences of
in sections 2.5.1 and 2.5.3.

I would really appreciate some feedback, but I am quite certain that this
new text will really clear up many issues that were raised in #50.

[...]
2.5  Role of Diameter Agents

   In addition to client and servers, the Diameter protocol introduces
   relays, redirectors, proxies and translation gateways, each of which
   is defined in Section 1.3. These Diameter agents are useful for
   several reasons:
      - They can distribute administration of systems to a configurable
        grouping, including the maintenance of security associations.
      - They can be used for concentration of requests from an number of
        co-located or distributed NAS equipment sets to a set of like
        user groups.
      - They can do value-added processing to the requests or responses.
      - They can used for load balancing.
      - A complex network will have multiple authentication sources,
        they can sort requests and forward towards the correct target.

   The Diameter protocol requires that agents maintain transaction
   state, which is used for failover purposes. Transaction state implies
   that upon forwarding a request, it's Hop-by-Hop identifier is saved,
   the field is replaced with a locally unique identifier, which is
   restored to its original value when the corresponding answer is
   received. The request's state is released upon receipt of the answer.
   A stateless agent is one that only maintains transaction state.

   The Proxy-Info AVP allows stateless agent to add local state to a
   Diameter request, with the guarantee that the same state will be
   present in the answer. However, the protocol's failover procedures
   requires that agents maintain a copy of pending requests.

   A stateful agent is one that maintains session state information, by
   keeping track of all authorized active sessions. Each authorized
   session is bound to a particular service, and its state is considered
   active either until it is notified otherwise, or by expiration. Each
   authorized session has a expiration, which is communicated by
   Diameter servers via the Authorized-Lifetime AVP.

Calhoun et al.            expires October 2001                 [Page 16]

Internet-Draft                                                  May 2001

   Maintaining session state MAY be useful in certain applications, such
   as:
      - Protocol translation (e.g. RADIUS <-> Diameter)
      - Limiting resources authorized to a particular user
      - Per user or transaction auditing

   A Diameter agent MAY act in a stateful manner for some requests,
   while be stateless for others. A Diameter implementation MAY act as
   one type of agent for some requests, and as another type of agent for
   others.

2.5.1  Relay Agents

   Relay Agents are Diameter agents that accept requests and routes the
   message to another Diameter agent based on information found in the
   message (e.g. Destination-Realm). This routing decision is performed
   using a list of supported domains, and known peers. This is known as
   the Diameter Routing Table, as is defined further in section x.x.

   Relays MAY be used to aggregate requests from multiple Network Access
   Servers (NASes) within a common geographical area (POP). The use of
   Relays is advantageous since it eliminates the need for NASes to be
   configured with the necessary security information it would otherwise
   require to communicate with Diameter servers in other realms.
   Likewise, this reduces the configuration load on Diameter servers
   that would otherwise be necessary when NASes are added, changed or
   deleted.

   Relays modify Diameter messages by inserting, and removing, routing
   information, but do not modify any other portion of a message.
   Further, Relays inherent simplicity implies that they are stateless,
   and therefore SHOULD NOT maintain session state, but MUST maintain
   transaction state.

      +------+    --------->     +------+     --------->    +------+
      |      |    1. Request     |      |     2. Request    |      |
      | NAS  |                   | DRL  |                   | HMS  |
      |      |    4. Answer      |      |     3. Answer     |      |
      +------+    <---------     +------+     <---------    +------+
      mno.net                     mno.net                    abc.com
                  Figure 1: Relaying of Diameter messages

   The example provided in Figure 1 depicts a request issued from NAS,
   which is an access device, for the user [email-masked]. Prior to issuing
   the request, NAS performs a Diameter route lookup, using "abc.com" as
   the key, and determines that the message is to be relayed to DRL,
   which is a Diameter Relay. DRL performs the same route lookup as NAS,

Calhoun et al.            expires October 2001                 [Page 17]

Internet-Draft                                                  May 2001

   and relays the message to HMS, which is abc.com's Home Diameter
   Server. HMS identifies that the request can be locally supported (via
   the realm), processes the authentication and/or authorization
   request, and replies with an answer, which is routed back to NAS
   using Diameter routing AVPs.

   Since Relays do not perform any application level processing, they
   provide relaying services for all Diameter applications, and
   therefore MUST advertise the Relay Application Identifier.

2.5.2  Proxy Agents

   Similarly to Relays, Proxy agents route Diameter messages using the
   Diameter Routing Table. However, they differ since they modify
   messages to implement policy enforcement. This requires that proxies
   maintain the state of their downstream peers (e.g. access devices) to
   enforce resource usage, provide admission control, and provisioning.

   It is important to note that although proxies MAY provide a value-add
   function for NASes, they do not allow access devices to use the
   Diameter End-to-End Security application, since modifying messages
   breaks end-to-end authentication.

   Proxies MAY be used in call control centers or access ISPs that
   provide outsourced connections, they can monitor the number and types
   of ports in use, and make allocation and admission decisions
   according to their configuration.

   Proxies that wish to limit resources MUST be stateful, and all
   Proxies MUST maintain transaction state.

   Proxy agents MUST NOT allow end-to-end security to be established
   between two peers if it expects to modify ANY non-routing AVP in
   messages exchanged between the peers. See [11] for more information.

   Since enforcing policies requires an understanding of the service
   being provided, Proxies MUST only advertise the Diameter applications
   they support.

2.5.3  Redirector Agents

   Redirector agents provide Realm to Server address resolution, and use
   the Diameter routing table to determine where a given request should
   be forwarded to. When a request is received by a Diameter redirector,
   a special answer is created, which includes the identity of the
   Diameter server(s) the originator of the request should contact

Calhoun et al.            expires October 2001                 [Page 18]

Internet-Draft                                                  May 2001

   directly.

   Redirectors are useful in scenarios where the Diameter routing
   configuration needs to be centralized. An example is a redirector
   that provides services to all members of a consortium, but does not
   wish to be burdened with relaying all messages between domains.  This
   scenario is advantageous since it does not require that the
   consortium provide routing updates to its members when changes are
   made to a member's infrastructure.

   Since redirectors do not relay messages, and only return an answer
   with the information necessary for Diameter agents to communicate
   directly, they do not modify messages, and therefore MUST NOT
   maintain session state. Further, since redirectors never relay
   requests, they are not required to maintain transaction state.

                                 +------+
                                 |      |
                                 | DRD  |
                                 |      |
                                 +------+
                                  ^    |
                      2. Request  |    | 3. Redirection
                                  |    |    Notification
                                  |    v
      +------+    --------->     +------+     --------->    +------+
      |      |    1. Request     |      |     4. Request    |      |
      | NAS  |                   | DRL  |                   | HMS  |
      |      |    6. Answer      |      |     5. Answer     |      |
      +------+    <---------     +------+     <---------    +------+
      mno.net                     mno.net                    abc.com
                 Figure 2: Redirecting a Diameter Message

   The example provided in Figure 2 depicts a request issued from the
   access device, NAS, for the user [email-masked]. The message is
   forwarded by the NAS to its relay, DRL, which does not have a routing
   entry in its Diameter Routing Table for abc.com. DRL has a default
   route configured to DRD, which is a redirector that returns a
   redirect notification to DLR, as well as HMS' contact information.
   Upon receipt of the redirect notification, DRL establishes a
   transport connection with HMS, if one doesn't already exist, and
   forwards the request to it.

   Since Redirectors do not perform any application level processing,
   they provide relaying services for all Diameter applications, and
   therefore MUST advertise the Relay Application Identifier.

Calhoun et al.            expires October 2001                 [Page 19]

Internet-Draft                                                  May 2001

2.5.4  Translation Agents

   A Translation Agent is a device that provides translation between two
   protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation
   agents are likely to be used as aggregation servers to communicate
   with a Diameter infrastructure, while allowing for the embedded
   systems to be migrated at a slower pace.

   Given that the Diameter protocol introduces the concept of long-lived
   authorized sessions, translation agents MUST be stateful and MUST
   maintain transaction state.

   Translation of messages can only occur if the agent recognizes the
   application of a particular request, and therefore MUST only
   advertise their locally supported extensions.

      +------+    --------->     +------+     --------->    +------+
      |      |  RADIUS Request   |      |  Diameter Request |      |
      | NAS  |                   | TLA  |                   | HMS  |
      |      |  RADIUS Answer    |      |  Diameter Answer  |      |
      +------+    <---------     +------+     <---------    +------+
      mno.net                     mno.net                    abc.com
                Figure 3: Translation of RADIUS to Diameter

[...]

5.0  Diameter message processing

   All Diameter messages MUST include the Origin-Host and Origin-Realm
   AVPs, which are used to identify the source of the message.  The
   Destination-Host AVP MAY be present in requests, and MUST be present
   in answers. The Destination-Host AVP is used when the destination of
   the message is fixed, which includes:

      - Authentication requests that span multiple round trips
      - A Diameter message that uses a security mechanism that makes use
        of a pre-established session key shared between the source and
        the final destination of the message.
      - Server initiated messages that MUST be received by a specific
        Diameter client (e.g. access device), such as the Abort-
        Session-Request message, which is used to request that a

Calhoun et al.            expires October 2001                 [Page 33]

Internet-Draft                                                  May 2001

        particular user's session be terminated.

   The Destination-Realm AVP MUST be present if the message is routable.
   A message that MUST NOT be relayed, proxied or redirected MUST NOT
   include the Destination-Realm in its ABNF. The value of the
   Destination-Realm AVP MAY be extracted from the User-Name AVP, or
   other application-specific methods.

   When a message is received, the message is processed in the following
   order:
      1. If the message is destined for the local host, the procedures
         listed in section 5.1 are followed.
      2. If the message is intended for a Diameter peer with whom the
         local host is able to directly communicate with, the procedures
         listed in section 5.2 are followed. This is known as Message
         Forwarding.
      3. The procedures listed in section 5.3 are followed, which is
         known as Message Routing.
      4. If none of the above are successful, an answer is returned with
         the Result-Code set to DIAMETER_UNABLE_TO_DELIVER.

   Note the processing rules contained in this section are intended to
   be used as general guidelines to Diameter developers. Certain
   implementations MAY use different methods than the ones described
   here, and still be in compliance with the protocol specification.

5.1  Processing Local Messages

   A request is known to be for local comsumption when one of the
   following conditions occur:
      - The Destination-Host AVP contains the local host's identity,
      - The Destination-Host AVP is not present, the Destination-Realm
        AVP contains a realm the server is configured to process
        locally, and the Diameter application is locally supported, or
      - The Destination-Realm AVP is not present.

   When a request is locally processed, the following procedures MUST be
   applied, in addition to any additional procedures that MAY be
   discussed in the Diameter application defining the command:

      - The same Hop-by-Hop identifier in the request is used in the
        answer.
      - The local host's identity is encoded in the Origin-Host and
        Origin-FQDN AVPs.
      - The value of the Origin-Host AVP in the request is included in
        the answer's Destination-Host AVP.
      - The Result-Code AVP is added with its value indicating success

Calhoun et al.            expires October 2001                 [Page 34]

Internet-Draft                                                  May 2001

        or failure.
      - If the Session-Id is present in the request, it MUST be included
        in the answer.
      - Any Route-Record or Proxy-Info AVPs in the request MUST be added
        to the answer message, in the same order they were present in
        the request.

   When the local message is an answer, no additional procedures beyond
   those listed in the specific Diameter application are to be followed.

5.2  Message Forwarding

   Message forwarding is done using the Diameter Peer Table. The
   Diameter peer table contains all of the peers that the local node is
   able to directly communicate with.

   When a request is received, and the host encoded in the Destination-
   Host AVP is one that is present in the peer table, the message SHOULD
   be forwarded to the peer.

   If the message received is an answer, the host in the Destination-
   Host AVP is in the peer table, and there are no Route-Record AVPs in
   the message, the message MUST be forwarded to the peer.

5.2.1  Peer Table

   The Diameter Peer Table is used in message forwarding, and referenced
   by the Domain Routing Table. A Peer Table entry contains the
   following fields:
      - Peer name. The Fully Qualified Domain Name of the peer. This MAY
        be resolved locally, or known via the DRR or DRA message.
      - Port Number. The port number the peer may be contacted on.
      - Protocol. Specifies whether TCP or SCTP is the protocol to use
        to communicate with the peer.
      - TLS Enabled. Specifies whether TLS is to be used when
        communicating with the peer.

5.3  Message Routing

   Diameter request message routing is done via realms. A Diameter
   message that is proxyable MUST include the target realm in the
   Destination-Realm AVP. The realm MAY be retrieved from the User-Name
   AVP, which is in the form of a Network Access Identifier (NAI). The
   realm portion of the NAI is inserted in the Destination-Realm AVP.

Calhoun et al.            expires October 2001                 [Page 35]

Internet-Draft                                                  May 2001

   Diameter agents have a list of locally supported realms, and MAY have
   a list of externally supported realms. When a request is received
   that includes a realm that is not locally supported, the message is
   routed to the peer configured in the Domain Routing Table table (see
   section 5.3.1).

5.3.1  Realm-Based Routing Table

   All Realm-Based routing lookups are performed against what is
   commonly known as the Domain Routing Table (see section 18.0). A
   Domain Routing Table Entry contains the following fields:
      - Domain Name. The Domain Name is analogous to the realm portion
        of the NAI.  This is the field that is typically used as a
        primary key in the routing table lookups. Note that some
        implementations perform their lookups based on longest-match-
        from-the-right on the realm rather than requiring an exact
        match.
      - Application Identifier. It is possible for a routing entry to
        have a different destination based on the Acct-Application-Id
        (for accounting messages) or Auth-Application-Id (for non-
        accounting messages) of the message. This field is typically
        used as a secondary key field in routing table lookups.
      - Local Action. The Local Action field is used to identify how a
        message should be treated. The following actions are supported:
           1. LOCAL - Diameter messages that resolve to a routing entry
              with the Local Action set to Local can be satisfied
              locally, and do not need to be routed to another server.
           2. RELAY - All Diameter messages that fall within this
              category MUST be routed to a next hop server, without
              modifying any non-routing AVPs. See sections 5.3.3 and
              5.3.4 for relaying guidelines
           3. PROXY - All Diameter messages that fall within this
              category MUST be routed to a next hop server. The local
              server MAY apply its local policies to the message by
              including new AVPs to the message prior to routing.  See
              sections 5.3.3 and 5.3.4 for relaying guidelines.
           4. REDIRECT - Diameter messages that fall within this
              category MUST have the identity of the home Diameter
              server(s) appended, and returned to the sender of the
              message. See section 5.3.2 for redirect guidelines.
      - Server Identifier - One or more servers the message is to be
        routed to.  These servers MUST also be present in the Peer
        table. When the Local Action is set to RELAY or PROXY, this
        field contains the identity of the server(s) the message must be
        routed to. When the Local Action field is set to REDIRECT, this
        field contains the identity of one or more servers the message
        should be redirected to.

Calhoun et al.            expires October 2001                 [Page 36]

Internet-Draft                                                  May 2001

   It is important to note that Diameter agents MUST support at least
   one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents
   do not need to support all modes of operation in order to conform
   with the protocol specification, but MUST follow the protocol
   compliance guidelines in section 2.0. Relay agents MUST NOT reorder
   AVPs, and proxies SHOULD NOT reorder AVPs.

   When a request is routed, the target server MUST have advertised the
   Application Identifier (see section 6.1) for the given message, or
   have advertised itself as a relay or proxy agent.

5.3.2  Redirecting requests

   When a redirector agent receives a request whose routing entry is set
   to REDIRECT, it MUST answer the request with Message-Reject-Answer,
   while maintaining the Hop-by-Hop Identifier in the header, and
   include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of
   the servers associated with the routing entry are added in separate
   Redirect-Host AVP.

                     +------------------+
                     |     Diameter     |
                     | Redirector Agent |
                     +------------------+
                      ^    |
           1. Request |    | 2. MRA +
          [email-masked] |    | Result-Code = DIAMETER_REDIRECT_INDICATION +
                      |    | Redirect-Host AVP(s)
                      |    v
                    +---------+  3. Request  +----------+
                    | abc.net |------------->| xyz.net  |
                    |  Relay  |              | Diameter |
                    |  Agent  |<-------------|  Server  |
                    +---------+  4. Answer   +----------+
                    Figure 7: Diameter Redirect Server

   Redirector agents MAY also include the certificate of the servers in
   the Redirect-Host AVP(s). These certificates are encapsulated in a
   CMS-Cert AVP [11].

   The receiver of the MRA message with the Result-Code AVP set to
   DIAMETER_REDIRECT_INDICATION uses the hop-by-hop field in the
   Diameter header to identify the request in the pending message queue
   (see Section 7.3) that is to be redirected. If no transport
   connection exists with the new agent, one is created, and the request
   is sent directly to it.

Calhoun et al.            expires October 2001                 [Page 37]

Internet-Draft                                                  May 2001

5.3.3  Relaying and Proxying Requests

   A relay or proxy agent MUST check for forwarding loops before
   forwarding requests. A loop is detected if the server finds its own
   address in a Route-Record AVP. When such an event occurs, the agent
   MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

   A relay or proxy agent MUST append a Route-Record AVP that includes
   its identity to all requests forwarded. The last Route-Record AVP in
   all requests received MUST be validated, by ensuring that the host
   encoded in the AVP is the same as the peer the message was received
   from.

   The Hop-by-Hop identifier in the request is saved, and replaced with
   a locally unique value.

   Relay and Proxy agents MAY include the Proxy-Info AVP in requests if
   it requires access any local state information when the corresponding
   response is received. Alternatively, it MAY simply use local storage
   to store state information.

   The message is then forwarded to the next hop, as identified in the
   Domain Routing Table.

   Figure 6 provides an example of message routing using the procedures
   listed in these sections.

          (Origin-Host=nas.mno.net)    (Origin-Host=nas.mno.net)
          (Origin-Realm=mno.net)       (Origin-Realm=mno.net)
          (Destination-Realm=abc.com)  (Destination-Realm=abc.com)
                                       (Route-Record=drl.mno.net)
      +------+      ------>      +------+      ------>      +------+
      |      |     (Request)     |      |      (Request)    |      |
      | NAS  +-------------------+ DRL  +-------------------+ HMS  |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
      mno.net      (Answer)      mno.net       (Answer)     abc.com
          (Origin-Host=hms.abc.com)   (Origin-Host=hms.abc.com)
          (Origin-Realm=abc.com)      (Origin-Realm=abc.com)
      (Destination-Host=nas.mno.net)  (Destination-Host=nas.mno.net)
                                      (Route-Record=drl.mno.net)
                  Figure 6: Routing of Diameter messages

5.3.4  Relaying and Proxying Answers

   A relay or proxy agent MUST only process Answers whose last Route-
   Record AVP matches one of its identities. Any answers that do not

Calhoun et al.            expires October 2001                 [Page 38]

Internet-Draft                                                  May 2001

   conform to this rule MUST be dropped. The last Route-Record AVP MUST
   be removed from the message before it is forwarded to the next hop,
   which is identified by the second to last Route-Record AVP.

   If the last Proxy-Info AVP in the message is targeted to the local
   Diameter server, the AVP MUST be removed.

   If a relay or proxy agent receives an answer with a Result-Code AVP
   indicating a failure, it MUST NOT modify the contents of the AVP. Any
   additional local errors detected SHOULD be logged, but not reflected
   in the Result-Code AVP. If the agent receives an answer message with
   a Result-Code AVP indicating success, and it wishes to modify the AVP
   to indicate an error, it MUST issue an STR on behalf of the access
   device.

   Prior to forwarding the answer, the agent MUST restore the original
   value of the Diameter header's Hop-by-Hop Identifier field.

5.4.6  Hiding Network Topology

   A Relay or Proxy agent routing messages outside of their
   administrative domain MAY need to hide the internal Diameter
   topology. This is done by removing all Route-Record AVPs in a
   request, and later adding them back into the corresponding answer, in
   the same order. Such agents MUST take care to not assume that the
   absence of any Route-Record AVPs implies the message is for local
   comsumption.

5.5  Origin-Host AVP

   The Origin-Host AVP (AVP Code 264) is of type OctetString, encoded in
   the UTF-8 [24] format, according to the Diameter identity rules
   defined in section 2.7, and MUST be present in all Diameter messages.
   This AVP identifies the endpoint which originated the Diameter
   message, i.e. the access device, home server, or broker. Relay agents
   MUST NOT modify this AVP.

   Note that the Origin-Host AVP may resolve to more than one address as
   the Diameter peer may support more than one address.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

5.6  Origin-Realm AVP

Calhoun et al.            expires October 2001                 [Page 39]

Internet-Draft                                                  May 2001

   The Origin-Realm AVP (AVP Code 296) is of type OctetString, encoded
   in the UTF-8 [24] format. This AVP contains the Realm of the
   originator of any Diameter message and MUST be present in all
   messages

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

5.7  Destination-Host AVP

   The Destination-Host AVP (AVP Code 293) is of type OctetString,
   encoded in the UTF-8 [24] format, according to the Diameter identity
   rules defined in section 2.7. This AVP MUST be present in all
   unsolicited agent initiated messages, MAY be present in request
   messages, and MUST be present in Answer messages. The value of the
   Destination-Host AVP is set to the value of the Origin-Host AVP found
   in a message from the intended target host.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

5.8  Destination-Realm AVP

   The Destination-Realm AVP (AVP Code 283) is of type OctetString,
   encoded in the UTF-8 [24] format, and contains the realm the message
   is to be routed to. The Destination-Realm AVP MUST NOT be present in
   Answer messages.  Diameter Clients insert the realm portion of the
   User-Name AVP. Diameter servers initiating a request message use the
   value of the Origin-Realm AVP from a previous message received from
   the intended target host (unless it is known a priori). When present,
   the Destination-Realm AVP is used to perform message routing
   decisions.

   Request messages whose ABNF does not list the Destination-Realm AVP
   as a mandatory AVP are inherently non-routable messages.

   This AVP SHOULD be placed as close to the Diameter header as
   possible.

5.9  Route-Record AVP

   The Route-Record AVP (AVP Code 282) is of type OctetString, encoded
   in the UTF-8 [24] format, according to the Diameter identity rules
   defined in section 2.7. The identity added in this AVP MUST be the
   same as the identity sent in the Origin-Host of the Device-Reboot-

Calhoun et al.            expires October 2001                 [Page 40]

Internet-Draft                                                  May 2001

   Request message.

5.10  Proxy-Info AVP

   The Proxy-Info AVP (AVP Code = 284) is of type Grouped.  The Grouped
   Data field has the following ABNF grammar:

      Proxy-Info ::= < AVP Header: 284 >
                     { Proxy-Host }
                     { Proxy-State }
                   * [ AVP ]

5.11  Proxy-Host AVP

   The Proxy-Host AVP (AVP Code = 280) is of type OctetString, encoded
   in the UTF-8 [24] format, according to the Diameter identity rules
   defined in section 2.7. This AVP contains the identity of the host
   that added the Proxy-Info AVP.

5.12  Proxy-State AVP

   The Proxy-State AVP (AVP Code = 33) is of type OctetString, and
   contains state local information, and MUST be treated as opaque data.

5.13  Redirect-Host AVP

   The Redirect-Host AVP (AVP Code 292) is of type OctetString, encoded
   in the UTF-8 [24] format, according to the Diameter identity rules
   defined in section 2.7. This AVP MUST be present in Message-Reject-
   Answer messages that include the Result-Code AVP set to
   DIAMETER_REDIRECT_INDICATION.

   Upon receiving the above, the receiving Diameter node SHOULD forward
   the request directly to the host identified in this AVP.