Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs

From: [email-masked]
Date: Wed, 21 Feb 2001 12:06:43 -0500 (EST)

On Mon, 12 Feb 2001, Patrice Calhoun wrote:

> I think that one of the fundamental problems with RADIUS is it's
> lack of specification in proxying. I believe that it doesn't hurt
> to "suggest" how a proxy can route packets, and let the more
> experienced developers come up with better scheme. This way we can
> assume that all Diameter implementations will at least do what the
> protocol was intended to do.

There have been numerous assumptions about how proxies should work.  
I think one of the biggest problem with RADIUS is an assumed proxy
functionality based upon doing minimal manipulation of AVPs.

Diameter carries this flaw even further by attempting to mix proxy
behavior specification into the base protocol.  For example, the
Host-Name AVP is defined to be carried unchanged through proxies.  
This behavior is really be dependent upon the type of proxy being
deployed and should not be required (I note draft-aaa-diameter-00.txt
does not actually say "MUST not modify" but instead says "proxy
servers do not modify").

If we can identify useful protocol elements which might help some
proxy environments, then by all means define them in the base
protocol.  However, don't use them to enforce certain proxy behavior.

If the Diameter specification is only suggesting how a proxy can route
packets, should that discussion be in the standards track base
protocol specification?  A separate non standards track
(experimental?) document showing possible proxying situations could be
a useful document to suggest how proxies might operate.  Lets not mix
"might choose to do it this way" with the standards track protocol
behavior.

By moving the proxy behavior into a separate document we can simplify
the base protocol specification considerably.  Implementors of NASes
or other Diameter clients don't really need to be overly concerned
about the proxy behavior.  Likewise implementors of Diameter Servers
should also not need to be worried about the subtle difficulties of
proxies.  In fact, protocol-wise, proxy implementors only need to be
interested in the single hop behavior of each side of the proxy.

Stuart
-- 
Stuart A Barkley                        email: [email-masked]

[resend.  previous attempts seemed to go into a blackhole.]

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 23 Feb 2001 05:34:37 -0800 (PST)

> does not actually say "MUST not modify" but instead says "proxy

I am not sure I understand what you are stating. Are you requesting that the
do not modify be changed to MUST NOT modify?

> protocol.  However, don't use them to enforce certain proxy behavior.

The only ones that I know of are the routing AVPs, and routing is essential to
the protocol, so I don't see a problem in defining these. Could you be more
specific?

> "might choose to do it this way" with the standards track protocol

I think I now understand your concern. The might was put there explicitely to
satisfy Barney's insistence that we not define Proxy Behaviors. However,
without such text, I don't think we have a good routing story, and would
basically have RADIUS. I think that a good routing strategy needs to be
defined.

> interested in the single hop behavior of each side of the proxy.

Again, are you just talking about routing of messages here?

PatC

---

From: Barney Wolff <[email-masked]>
Date: Fri, 23 Feb 2001 10:47:06 -0500

While I would (reluctantly :) agree that RADIUS has its faults,
is under-specification of proxy routing behavior really one of
them?  Has any RADIUS proxy implementor ever asked plaintively
on the RADIUS list, "How do I decide where to forward the
request?"  Does anyone have a misrouting-by-design war story
to relate?  Bernard, would your tale of the proxy that messed
up some response AVPs have been any different if there had
been an RFC that said "Don't mess up AVPs?"

Barney

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Fri, 23 Feb 2001 09:53:24 -0800 (GMT-0800)

> them?  

I would say that the weakness is proxy/server discovery as much as 
routing. In practice, I doubt that routing loops will be a serious 
problem - although I suppose we should specify that the path list be 
checked. 

> Does anyone have a misrouting-by-design war story
> to relate?  

Nope. I do have stories about routing tables with missing entries, 
though. That's one reason why proxy/server discovery is in the solutions 
draft. I'd also note that similar functionality is in the Kerb/RADIUS 
draft by Kaushik. Being able to discover AAA servers via SLP, DNS SRV and 
DNS A RRs is a useful capability. 

> Bernard, would your tale of the proxy that messed

Actually, in the specific case cited, it was the *NAS* that disregarded 
AVPs, rather than silently discarding the packet or sending an error 
message. So the NAS was already in violation of RFC 2865 -- and so adding 
more language wouldn't have changed anything ;)