Subject: [AAA-WG]: Partial Proposed Fix for Issue 50

From: Pat Calhoun <[email-masked]>
Date: Tue, 29 May 2001 10:50:45 -0700

All,

Issue 50, submitted by Bernard, states that the Diameter document should
attempt to incorporate some portions of the proxy draft, and some of the
proxy discussions should be moved towards the beginning of the document.

Here is my attempted fix, which I'd like to get some feedback on.

Thanks,

PatC
----
2.5  Role of Diameter Agents

   In addition to client and servers, the Diameter protocol introduces
   relays, redirectors, proxies and translation agents, 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.

   Maintaining session state MAY be useful in certain applications, such
   as:

Calhoun et al.            expires October 2001                 [Page 16]

Internet-Draft                                                  May 2001

      - 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,
   and relays the message to HMS, which is abc.com's Home Diameter
   Server. HMS identifies that the request can be locally supported (via

Calhoun et al.            expires October 2001                 [Page 17]

Internet-Draft                                                  May 2001

   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.

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.

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

Calhoun et al.            expires October 2001                 [Page 18]

Internet-Draft                                                  May 2001

   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.

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.

Calhoun et al.            expires October 2001                 [Page 19]

Internet-Draft                                                  May 2001

   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