Subject: [AAA-WG]: Issue 74: Do not use Route-Record for answer routing

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 05:48:20 -0700

All,

Following our chat yesterday, we agreed with this issue. Basically, this
issue states that since each agent needs to maintain a list of pending
messages (for failover purposes), the presence of the Route-Record in
answer messages for routing purposes is superfluous. The list of pending
messages could easily include the source of the request, and including
the Route-Record AVP simply introduces the possibility for conflicting
information.

The following sections include the new text, and I would appreciate any
comments.

Thanks,

PatC
----
5.1.9  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. The source of the request is also saved,
   which includes the IP address, port and protocol.

   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)
                  Figure 6: Routing of Diameter messages

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 Destination-Host and Destination-Realm AVPs MUST NOT be
        present in the answer message.
      - 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 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.2  Relaying and Proxying Answers

   If the answer is for a request which was proxied or relayed, the
   agent MUST restore the original value of the Diameter header's Hop-
   by-Hop Identifier field.

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

   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.

   The agent MUST then send the answer to the host which it received the
   original request from.

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 additional changes to the tables in section 14, which I will not bother
to list here]