Subject: [AAA-WG]: [Issue] Request & answer routing clarification

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 13:10:35 +0200

Submitter name: Jacques Caron
Submitter email address: [email-masked]
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: E
Priority: 2
Section: throughout 5.x
Rationale/Explanation of issue:

It is necessary to clarify the use of Destination-Realm & Destination-Host 
in Request routing.

If I finally got it right, Destination-Host is used only to target a 
specific host within a number of servers serving a given realm. This is 
achieved by sending to that host when said host is in the peer table, 
otherwise Destination-Realm is used. When reading the draft, it looks like 
it is used to talk directly from the client to the specified server.

Should be described early in 5.0, not be spread over 5.0, 5.1, 5.2.

This is also somewhat linked to the proposed text for issue 56 (flag bit 
for start of conversation).

It is also necessary to clarify the following points for answer routing:
- it is completely different from request routing
- no Destination-Realm should be present

Other misc. changes:
- add default routing table entry description.
- change "Domain" to "Realm"
- clarify actions on origination and sending of message, including saving 
pending requests

Requested change:

Sorry, a bit long. The important changes are:
- added overview in 5.1, with 3 cases for Destination-Realm & Destination-Host
- added sections 5.1.1 & 5.1.2 about originated and sending a request
- separated request (5.1.x) and answer (5.2.x) processing & routing
- used "request" rather than message where it is needed to clarify things
- moved answer generation to 5.2
- changed "domain" to "realm" in routing table
- added default routing table entry discussion

The rest is mainly renumbering and moving stuff around.

Replace sections 5.0 to 5.3.5 with:

5.0  Diameter message processing

    This section describes how Diameter requests and answers are created
    and processed.

5.1  Diameter request routing overview

    A request is sent towards its final destination using a combination
    of the Destination-Realm and Destination-Host AVPs, in one of these
    three combinations:
       - a request that is not proxiable (such as CER) MUST NOT contain
	either Destination-Realm or Destination-Host AVPs.
       - a request that needs to be sent to a home server serving a
	specific realm, but not to a specific server (such as the first
	request of a series of round-trips), MUST contain a
	Destination-Realm AVP, but MUST NOT contain a Destination-Host
	AVP.
       - a request that needs to be sent to a specific home server among
	those serving a given realm, MUST contain both the
	Destination-Realm and Destination-Host AVPs.

    The Destination-Host AVP is used as described above when the
    destination of the request is fixed, which includes:
       - Authentication requests that span multiple round trips
       - A Diameter request that uses a security mechanism that makes use
	of a pre-established session key shared between the source and
	the final destination of the request.
       - Server initiated requests 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
	particular user's session be terminated.

    Note that an agent can forward a request to a host described in the
    Destination-Host AVP only if said host is included in its peer table
    (see sections 5.1.4 and 5.1.5). Otherwise, the request is routed
    based on the Destination-Realm only (see sections 5.1.6 and 5.1.7).

    The Destination-Realm AVP MUST be present if the request is routable.
    A request 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 request is received, the message is processed in the following
    order:
       1. If the request is destined for the local host, the procedures
       listed in section 5.1.1 are followed.
       2. If the request is intended for a Diameter peer with whom the
       local host is able to directly communicate with, the procedures
       listed in section 5.1.2 are followed. This is known as Message
       Forwarding.
       3. The procedures listed in section 5.1.4 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.1  Originating a Request

    When creating a request, on top of any other procedures described in
    the application definition for that specific request, the following
    procedures MUST be followed:
       - the Command-Code should be set to the appropriate value
       - the 'R' bit should be set
       - the End-to-End Identifier should be set to a locally unique
	value
       - the Origin-Host and Origin-Realm AVPs MUST be set to the
	appropriate values, used to identify the source of the message
       - the Destination-Host and Destination-Realm AVPs MUST be set to
	the appropriate values as described in section 5.1.

5.1.2  Sending a Request

    When sending a request, either originated locally, or as the result
    of a forwarding or routing operation, the following procedures MUST
    be followed:
       - the Hop-by-Hop Identifier should be set to a locally unique
	value
       - the message should be saved in the list of pending requests

    Other actions to perform on the message based on the particular role
    the agent is playing are described in the following sections.

5.1.3  Processing Local Requests

    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 rules in section 5.2 should
    be used to generate the associated answer.

5.1.4  Request Forwarding

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

5.1.5  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:
       - Host descriptor, as defined in section 2.7. This MAY be resolved
	locally, or known via the CER or CEA message.
       - TLS Enabled. Specifies whether TLS is to be used when
         communicating with the peer.
       - Security informations (keys, certificates...) as appropriate.

5.1.6  Request 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.

    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
    following section).

5.1.7  Realm-Based Routing Table

    All Realm-Based routing lookups are performed against what is
    commonly known as the Realm Routing Table (see section 16.0). A
    Realm Routing Table Entry contains the following fields:
       - Realm Name. 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 section 5.1.9 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
               section 5.1.9 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.1.8 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.

    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.

    The routing table MAY include a default entry which MUST be used for
    any requests not matching any of the other entries. The routing table
    MAY consist of only such an entry.

    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.1.8  Redirecting requests

[... unchanged from 5.3.2 in current draft ...]

5.1.9  Relaying and Proxying Requests

[... unchanged from 5.3.3 in current draft ...]

5.2  Diameter Answer Processing

    When an request is locally processed, the following procedures MUST
    be applied to create the associated answer, 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 AVP.
       - The value of the Origin-Host AVP in the request is included in
         the answer's Destination-Host AVP.
       - There MUST NOT be any Destination-Realm AVP present in the
	answer.
       - The Result-Code AVP is added with its value indicating success
         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.

5.2.1  Processing received Answers

    A diameter client or proxy MUST match the Hop-by-Hop Identifier in an
    answer received against the list of pending requests. The
    corresponding message should be removed from the list of pending
    requests. It SHOULD ignore answers received that do not match a
    known Hop-by-Hop Identifier.

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

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

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 13:52:47 +0200

I forgot to mention in the changes that I also modified the peer table 
description to use Host descriptors rather than host name, port, and 
protocol independently.

>Rationale/Explanation of issue:

[...]

>       - Security informations (keys, certificates...) as appropriate.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 12 Jun 2001 14:58:06 -0700

On Mon, Jun 11, 2001 at 01:10:35PM +0200, Jacques Caron wrote:
[...]
> It is necessary to clarify the use of Destination-Realm & Destination-Host 

ok

> it is used to talk directly from the client to the specified server.

correct.

> - added default routing table entry discussion

ok. after finally going over your comments, I've pretty much accepted all of the
changes, with some minor grammatical changes.

Thanks,

PatC