Subject: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200

From: "Yolanda Garcia-Serrano (ECE)" <[email-masked]>
Date: Mon, 23 Apr 2001 05:02:28 -0400 (EDT)

Hi, Pat and al. 
Here goes some questions/proposals for message forwarding and routing sections (5, and 12) of
base 02:

First of all: Why splitting the issue in two separate sections, 5.0 and 12.0. They are very closely
related, aren't there? To understand the hole thing, one should go to both sections, so I suggest to merge them. 
In that way, it would be clearer. E.g. it is weird to see Destination-FQDN and Destination-Realm AVP stated
one in section 5.3, and the other in 12.4.7

Section 5.0 Message Forwarding.-
-----------------------------------
Replace NAS by Diameter client or access-device

2nd paragraph:
   When a Diameter entity receives a Diameter message of type Request,
   Query or Indication that includes a Destination-FQDN AVP, and the
   host specified in the AVP can be contacted directly, the message MUST
   be forwarded to the host in question.
and 4th paragraph:
   Proxies receiving messages that contain the Destination-FQDN AVP MUST
   verify whether they are able to forward Diameter messages to the host
   specified in the AVP, and if so, MUST forward the message to the host
   in question. Otherwise, the message routing procedures described in
   section 12.0 MUST be followed.
both try to say the same thing, but last one is much clearer, as it includes what to do in case
Destination-FQDN AVP is not present. So, could we get rid of 2nd paragraph?

Regarding Responses, Answers, and Replys, I've looking carefully to the draft, and it seems consufing:
In section 3.0, when talking about the flags, there are following message types: Request, Query, Indication, 
Reply and Answer. But in section 3.3.2 is stated Query/Response. So it is confusing.
I understand the term "response" refers to the generic one, and it includes both
Reply and Answer, isn't it?. Is it possible to make this clear in the spec, so that all this terms are
coherently used? 
Furthermore, why is needed any distinction between them? If there is no strong argument maybe we can get
rid of Request/Query and Response/Reply/Answer difference, and simply talk about Requests and
Responses through all the spec.

Last paragraph in section 5.0 refers to mandatory AVPs for all messages
   This section defines the Diameter AVPs that MUST be added in all
   messages originated by a Diameter node (including nodes creating
   Response and Answer messages).
but Destination-FQDN is used in Indication, Reply and Answers only, so, it should not belong to this
chapter, or better, this last paragraph in section 5.0 can be removed, as it adds no information, but 
it can lead to confusion about this Destination-FQDN AVP.

Section 5.3 Destination-FQDN AVP
   The Destination-FQDN AVP (AVP Code 293) is of type OctetString,
   encoded in the UTF-8 [24] format, and contains the Fully Qualified
   Domain Name (FQDN) of the intended recipient of the message. This AVP
   MUST be present in all unsolicited server initiated messages. The
   value of the Destination-FQDN AVP is set to the value of the Origin-
   FQDN AVP found in a message from the intended target host.
Should instead, state: "This AVP MUST be present in all unsolicited server initiated 
messages, all reply and all answer messages." See example in section 12.1 and AVP tables
16.1 and 16.2.

Section 12.0 Message Routing
-----------------------------------

Section 12.1 Realm-based message routing
   Diameter request, query and indication message routing is done
   through the use of the realm portion of the Network Access Identifier
   (NAI) or via a realm encoded in an AVP (e.g. Origin-Realm,
   Destination-Realm), and an associated realm routing table (see
   section 12.1.1).

   When an NAI is used, the realm portion of the user@realm is used to
   perform the realm lookup. Diameter servers have a list of locally
   supported realms, and MAY have a list of externally supported realms.
   When a request, query or indication message is received that includes
   a realm that is not locally supported, the message is proxied to the
   Diameter entity configured in the "route" table.
NAI is not used to route, is it? It should state instead :
      Diameter request, query and indication message routing is done through 
      the use of Destination-FQDN or Destination-Realm and an associated realm 
     routing table (see section 12.1.1).

   When an NAI is used, the realm portion of the user@realm MUST be copied in
   Destination-Realm AVP, which is used to perform the realm lookup. Diameter servers 
   have a list of locally supported realms, and MAY have a list of externally 
   supported realms.
   When a request, query or indication message is received that includes
   a realm that is not locally supported, the message is proxied to the
   Diameter entity configured in the "route" table.

Example DIA1, DIA2, DIA3, on figure 2:
          (Origin-FQDN=dia1.mno.net)   (Origin-FQDN=dia1.mno.net)
          (Origin-Realm=mno.net)       (Origin-Realm=mno.net)
          (Destination-Realm=abc.com)  (Destination-Realm=abc.com)
          (Route-Record=dia1.mno.net)  (Route-Record=dia1.mno.net)
                                       (Route-Record=dia2.xyz.com)
      +------+      ------>      +------+      ------>      +------+
      |      |     (Request)     |      |      (Request)    |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
      mno.net      (Response)    xyz.com      (Response)     abc.com
          (Origin-Realm=abc.com)       (Origin-Realm=abc.com)
      (Destination-FQDN=dia1.mno.net)  (Destination-FQDN=dia1.mno.net)
                                       (Route-Record=dia2.xyz.com)

Route-Record=dia1.mno.net is missing in Responses from DIA3 to DIA2 and DIA2 to DIA1 (this
has already been posted in the list).
Is it not missing as well Origin-FQDN = dia3.abc.com in Responses from DIA3 to DIA2 and DIA2 to
DIA1, as Origin-FQDN is MANDATORY in ALL Diameter messages?
I miss as well how the Response is routed back to the Diameter client (which is not present in the drawing,
and it will made it clearer, as DI1 is not the originator of the message, but the first proxy). With Destination-FQDN
set to DIA1, how the response can reach the client ?
The following figure, may help (in case Client belong to same domain than DIA1):

(Origin-FQDN=client.mno.net)   (Origin-FQDN=client.mno.net)     (Origin-FQDN=client.mno.net)
(Origin-Realm=mno.net)         (Origin-Realm=mno.net)           (Origin-Realm=mno.net)
(Destination-Realm=abc.com)    (Destination-Realm=abc.com)      (Destination-Realm=abc.com)
                               (Route-Record=dia1.mno.net)      (Route-Record=dia1.mno.net)
                                                                (Route-Record=dia2.xyz.com)
  +------+  -------->  +------+    ------>     +------+    ------>    +------+
  | DIA  | (Request)   |      |   (Request)    |      |  (Request)    |      |
  |Client|-------------| DIA1 +----------------+ DIA2 +---------------+ DIA3 |
  |      |             |      |                |      |               |      |
  +------|  <--------  +------+   <-------     +------+   <-------    +------+
  mno.net  (Response)   mno.net  (Response)     xyz.com   (Response)   abc.com
    (Origin-FQDN=dia3.abc.com)    (Origin-FQDN=dia3.abc.com)        (Origin-FQDN=dia3.abc.com)
    (Origin-Realm=abc.com)        (Origin-Realm=abc.com)            (Origin-Realm=abc.com)
(Destin-FQDN=client.mno.net)      (Destin-FQDN=client.mno.net)      (Destin-FQDN=client.mno.net)
                                  (Route-Record=dia1.xyz.com)       (Route-Record=dia2.xyz.com)
                                                                    (Route-Record=dia1.xyz.com)

Section 12.2Proxy and Redirect Server handling of requests

   When a message of type request, query or indication is received by a
   proxy or redirect server, and it is determined that the request
   cannot be locally handled, the next hop for the request is determined
   in the following order:
      1. If the Destination-FQDN AVP is present, and the host specified
         in the AVP can be directly contacted, the message is forwarded
         to the host (see section 5.3 for more information), or
      2. If the Destination-Realm AVP is present, a routing table lookup
         is performed using the domain specific in the AVP.
Could be explicitly said in 2.  and 12.4.7 that Destination-Realm AVP is mandatory for all Request, Query
and Indication messages ?

   A message that does not contain any of the above AVPs MUST NOT be
   routed.  If the message in question cannot be handled locally, a
   Message-Reject-Ind is sent with the Result-Code AVP set to an
   appropriate error condition.
This paragraph can be removed, if it is said than Destination-Realm AVP is mandatory.

Section 12.4  Proxy Server
   Maintaining transaction state implies that a server keeps a copy of a
   request, which is then used when the corresponding response is
   received.  This could be done to apply local policies to the message,
   or simply for auditing purposes. Maintaining session state implies
   that a server keeps track of all "active" users. An active user is
   one that has been authorized for a particular service, and the server
   has not received any indication that the user has relinquished
   access.

Say instead:  Maintaining transaction state implies that a server keeps a 
      copy of a request or query which is then used when the corresponding response is
   received.

   A stateless proxy is one that does not maintain session state, but
   MUST maintain transaction state. Transaction state SHOULD be released
   after a request's corresponding response has been forwarded towards
   the recipient, and has been acknowledged by the underlying transport.
Isn't it strange to call a proxy which keeps transaction state "stateless"? Maybe the paragraph can be
reworded to explain that what is considered "stateless" is a proxy that mantains the minimum information
about the forwarded messages (e.g. it stores Hop-by-Hop identifier and restore it after receiving the
corresponding Responses, it may add Proxy-State AVP ...).

Section 12.4.1  Proxying Requests
Could we title it Proxying Requests, Querys and Indications, instead ?
Spelling: A Diameter server that proxies a message of type Request, Query or ...

Section 12.4.2  Proxying Responses
   A proxy server MUST only process messages of type Response or Answer
   whose last Route-Record AVP matches one of its addresses.
Say instead: A proxy server MUST only process messages of type Reply or Answer
   whose last Route-Record AVP matches one of its identities. (IP addreses are
not used for this application routing, but  FQDN/realm).

Section 12.6  Hiding Network Topology
   Stateful proxies forwarding requests to servers outside of their
   administrative domain MAY hide the internal network topology. Servers
   perform this by removing all Route-Record AVPs in the message, and
   maintains the Route-Record AVPs to add to the corresponding response.
   Such stateful servers MUST still add their own Route-Record AVP to
   the request prior to forwarding.
Why the paragraph refers only to stateful proxies? I think it could also apply to stateless ones, if
we consider a proxy server including a Proxy-State as stateless.

Section 12.7  Loop Detection
   When a Diameter Proxy or Redirect server receives a message of type
   Request, Query or Indication, it MUST examine all Route-Record AVPs
   in the message to determine whether such an AVP already exists with
   the local server's identity. If an AVP with the local host's identity
   is found in the request, it is an indication that the message is
   being looped through the same set of proxies. When such an event
   occurs, the Diameter server that detects the loop returns a response
   with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

Instead of returning a response (this is impossible for Indications), I think it should say "the Diameter
server that detects the loop issues a Message-Reject-Ind message with the 
Result-Code AVP set to DIAMETER_LOOP_DETECTED."

Last one: Has it sense try to detect loops also for Reply/Answer messages? Say a loop is not properly
detected in an upstream Diameter message. Then, the same loop is going to happen for its corresponding
downstream response. So, maybe it would be more robust try to detect it as well for responses.
If you agree, it should be mentioned in this section.

BR
	/Yolanda Garcia

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 24 Apr 2001 15:55:07 -0700 (PDT)

> Here goes some questions/proposals for message forwarding and routing
> sections (5, and 12) of base 02:
> 
> First of all: Why splitting the issue in two separate sections, 5.0 and
> 12.0. They are very closely related, aren't there? 

Related, but different. A message that is processed according to section 5.0
will not be processed. There are messages that are subjected to such rules,
such as the DRI and the DSI.

> To understand the hole
> thing, one should go to both sections, so I suggest to merge them.  In that
> way, it would be clearer. E.g. it is weird to see Destination-FQDN and
> Destination-Realm AVP stated one in section 5.3, and the other in 12.4.7

So the Destination-FQDN is used in the message forwarding code, while the
Destination-Realm is used for forwarding purposes.

I will not object to merging them, but I would need to have more people that
think that this is needed.

> Section 5.0 Message Forwarding.-

ok

> both try to say the same thing, but last one is much clearer, as it includes
> what to do in case Destination-FQDN AVP is not present. So, could we get rid
> of 2nd paragraph?

You are correct. Removing the 2nd paragraph is a good idea since the 4th
paragraph was more specific.

> 
> Regarding Responses, Answers, and Replys, I've looking carefully to the
> draft, and it seems consufing: In section 3.0, when talking about the flags,
> there are following message types: Request, Query, Indication,  Reply and
> Answer. But in section 3.3.2 is stated Query/Response. So it is confusing. I
> understand the term "response" refers to the generic one, and it includes
> both Reply and Answer, isn't it?. Is it possible to make this clear in the
> spec, so that all this terms are coherently used? 

There was an unfortunate mistake in the draft from some text I pulled in from
a contribution, and I missed that one :(

Reply->Response

> Furthermore, why is needed any distinction between them? If there is no
> strong argument maybe we can get rid of Request/Query and
> Response/Reply/Answer difference, and simply talk about Requests and

We could, but there were cases where Queries exist, and these are a particular
type of message. See the Resource-Management (non WG document) as an example.

> but Destination-FQDN is used in Indication, Reply and Answers only, so, it
> should not belong to this chapter, or better, this last paragraph in section
> 5.0 can be removed, as it adds no information, but  it can lead to confusion
> about this Destination-FQDN AVP.

The Destination-FQDN CAN in fact be present in request or queries. This is
useful in messages that require multiple round trips, or when e2e security is
used, and the message has a specific target.

> Should instead, state: "This AVP MUST be present in all unsolicited server
> initiated  messages, all reply and all answer messages." See example in
> section 12.1 

I could modify the figure to include the AVP in the request, but it is not
mandatory to be present when the client doesn't care which server handles the
request.

> and AVP tables 16.1 and 16.2.

Table 16.1 shows the AVP as 0-1 in the STR, which is a request.

> Section 12.0 Message Routing

no. I believe that you are confused with the Destination-FQDN and the
Destination-Realm. The FQDN is used for hop-by-hop forwarding. It is only used
when the next hop is known. So the realm table doesn't need to be consulted,
but instead the peer table. This of this as similar to interfaces and routes.

> Route-Record=dia1.mno.net is missing in Responses from DIA3 to DIA2 and DIA2
> to DIA1 (this has already been posted in the list).

That is now fixed.

> Is it not missing as well Origin-FQDN = dia3.abc.com in Responses from DIA3
> to DIA2 and DIA2 to DIA1, as Origin-FQDN is MANDATORY in ALL Diameter
> messages? 

oops.

> I miss as well how the Response is routed back to the Diameter
> client (which is not present in the drawing, and it will made it clearer, as
> DI1 is not the originator of the message, but the first proxy). With
> Destination-FQDN set to DIA1, how the response can reach the client ?

DIA1 *is* the client. The client's FQDN is in the Destination-FQDN AVP.

> (Origin-FQDN=client.mno.net)   (Origin-FQDN=client.mno.net)    
> (Origin-FQDN=client.mno.net) (Origin-Realm=mno.net)        
> (Destination-Realm=abc.com)
>   |      |             |      |                |      |               |     
> |
> (Origin-Realm=abc.com) (Destin-FQDN=client.mno.net)     
> (Destin-FQDN=client.mno.net)      (Destin-FQDN=client.mno.net)
> Could be explicitly said in 2.  and 12.4.7 that Destination-Realm AVP is
> mandatory for all Request, Query and Indication messages ?

No because the presence of the Destionation-Realm implies that the message is
routable. There are many cases where that is not the case (again, DRI, DSI and
the watchdog messages are examples).

> This paragraph can be removed, if it is said than Destination-Realm AVP is

see above.
>       copy of a request or query which is then used when the corresponding

You are proposing just removing text?

> Isn't it strange to call a proxy which keeps transaction state "stateless"?

Yes perhaps, but a minimal amount of state is unavoidable :(

> Maybe the paragraph can be reworded to explain that what is considered
> "stateless" is a proxy that mantains the minimum information about the
> forwarded messages (e.g. it stores Hop-by-Hop identifier and restore it
> after receiving the corresponding Responses, it may add Proxy-State AVP ...).

You mean in addition to 

"
A stateless proxy is one that does not maintain session state, but MUST
maintain transaction state. Transaction state SHOULD be released after a
request's corresponding response has been forwarded towards the recipient,
and has been acknowledged by the underlying transport."

?

> Could we title it Proxying Requests, Querys and Indications, instead ?

ok

> Spelling: A Diameter server that proxies a message of type Request, Query or

thanks.

>    whose last Route-Record AVP matches one of its identities. (IP addreses
> are not used for this application routing, but  FQDN/realm).

correct.

>  > Section 12.6  Hiding Network Topology >    Stateful proxies forwarding
requests to servers outside of their >    administrative domain MAY hide the
internal network topology. Servers >    perform this by removing all
Route-Record AVPs in the message, and >    maintains the Route-Record AVPs to
add to the corresponding response. >    Such stateful servers MUST still add
their own Route-Record AVP to >    the request prior to forwarding. > Why the
paragraph refers only to stateful proxies? I think it could also > apply to
stateless ones, if we consider a proxy server including a > Proxy-State as
stateless.

ouch, don't know how the above occured.

In any case, you are correct, stateless servers could do this as well.

 >  >  > Section 12.7  Loop Detection >    When a Diameter Proxy or
Redirect server receives a message of type >    Request, Query or Indication,
it MUST examine all Route-Record AVPs >    in the message to determine whether
such an AVP already exists with >    the local server's identity. If an AVP
with the local host's identity >    is found in the request, it is an
indication that the message is >    being looped through the same set of
proxies. When such an event >    occurs, the Diameter server that detects the
loop returns a response >    with the Result-Code AVP set to
DIAMETER_LOOP_DETECTED. >  > Instead of returning a response (this is
impossible for Indications), I > think it should say "the Diameter server that
detects the loop issues a > Message-Reject-Ind message with the  Result-Code
AVP set to > DIAMETER_LOOP_DETECTED."

Correct.

 >  > Last one: Has it sense try to
detect loops also for Reply/Answer messages? > Say a loop is not properly
detected in an upstream Diameter message. Then, > the same loop is going to
happen for its corresponding downstream response. > So, maybe it would be more
robust try to detect it as well for responses. If > you agree, it should be
mentioned in this section.

Since the reverse path MUST be the same as the forwarding path, this is not
possible. If a loop exists, the packet would have never made it to the home to
begin with.

Thanks for the great comments!

PatC