Subject: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs

From: David Spence <[email-masked]>
Date: Tue, 24 Jul 2001 08:36:02 -0700

If a proxy or relay agent hides the topology by removing the Route-Record
AVPs, how does a home-server produce the list of Source-Route
AVPs which he needs to subsequently send a reverse-request?

Pertinent sections of draft-ietf-aaa-diameter-07.txt follow:
   
    6.1.9  Relaying and Proxying Server-Initiated Requests
 
    Server-initiated messages MUST include the Source-Route AVPs, whose
    contents are identical to the Record-Route AVPs received in requests
    from the access device for the given session, but in the reverse
    order. 
 
    6.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.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 24 Jul 2001 09:26:21 -0700

> AVPs which he needs to subsequently send a reverse-request?

I believe that some additional text will be needed in section 6.3
below that states that stateful proxies that hide topology MUST keep
the Record-Route path in case it receives a server-initiated
request.

Does that work?

PatC

---

From: David Spence <[email-masked]>
Date: Tue, 24 Jul 2001 23:31:37 -0700

> the Record-Route path in case it receives a server-initiated

I don't think so.  It works for stateful proxies, though it's more trouble
to program.  But sec. 6.3, below, doesn't specify that the agents removing
the Route-Record AVPs must be stateful.  And indeed they need not be
stateful in order to successfully remove Route-Record AVPs from a request
and still be able to process the answers.  So non-stateful agents that
remove Route-Record AVPs are still a problem.

It occurs to me, however, that removing Route-Record AVPs causes another
problem as well.  It defeats the whole purpose of Route-Record AVPs, namely,
to facilitate loop detection.  If Route-Record AVPs are removed and the
message somehow loops back through an agent downstream (closer to the
client) than the one that removed the Route-Record AVPs, then that agent
cannot detect a loop.  Of course, you may argue that the agent that removed
the Route-Record AVPs will detect the loop when the message gets back to
him.  But that is not necessarily the case because the agent to which he
forwarded the request may also have deleted Route-Record AVPs.

One solution to the problem, then, is to delete sec. 6.3, and not allow
agents to remove Route-Record AVPs.  A better solution, to my way of
thinking, is to abandon the idea of routing server-initiated requests by
using Source-Route AVPs and go back to routing them the same way client to
server requests are routed.

Given Bernard's request, I think I will post an issue for this problem.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: +1 734 821 1203
775 Technology Drive, Suite 200         fax:   +1 734 821 1235
Ann Arbor, MI 48108           
U.S.A.

---

From: David Spence <[email-masked]>
Date: Tue, 24 Jul 2001 23:58:50 -0700

I guess it's getting too late at night.  If removing Route-Record AVPs truly
defeats loop-detection, then the only single solution to both problems noted
in my previous message is not to allow removal of Route-Record AVPs.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 25 Jul 2001 06:38:48 -0700

> in my previous message is not to allow removal of Route-Record AVPs.

Do you mean to hide the path? So, removing section 6.3 would solve the
problem?

PatC

---

From: David Spence <[email-masked]>
Date: Wed, 25 Jul 2001 07:26:40 -0700

Pat Calhoun wrote:
>... 

Yes.