Subject: (radius) proxy issues, etc

From: Barney Wolff <[email-masked]>
Date: Wed, 3 Mar 1999 15:59 EST

I would be extremely wary of specifying proxy behavior other than that
strictly needed to function at all.  How the proxy decides which server
to send its request to, what attributes are passed along, whether proxy-
state is forwarded or saved, are all matters of implementation and of
no impact on the bits-on-the-wire between the NAS and the proxy.  It is,
really, not valid to speak of "forwarding" a request in the same sense
as forwarding a packet.  What the proxy is really doing is making an
independent request, and then using information in the corresponding
response, together with its own intelligence and database, to construct
a response to the original request.

Separately, count me as favoring a pool-selection attribute, and against
a call-failed acct status instead of terminate-cause codes in the stop.
NAS vendors are already doing the latter - why make everybody change?

I don't know whether to be glad or sorry I was out of the country this
past week.  Sure saved me a lot of time posting flames.

Barney Wolff  <[email-masked]>
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 3 Mar 1999 16:44:55 -0500

Barney Wolff writes...

> How the proxy decides which server
> to send its request to, what attributes are passed along, 
> whether proxy-state is forwarded or saved, are all matters
> of implementation and of no impact on the bits-on-the-wire
> between the NAS and the proxy.

Yes and no.  Strictly speaking, the protocol definition is
independent of the implementation issues you mention.  And if
all the NAS and RADIUS servers are from the same vendor the
issues are unlikely to be of concern.  However, when you
consider a multi-vendor environment, then I claim that the 
syntax and semantics of certain attributes do matter.  If
multi-vendor interoperability is a goal, then some common
understanding of how forwarding (proxying) decisions are made
is important. 

> It is, really, not valid to speak of "forwarding" a request
> in the same sense as forwarding a packet.
 
I agree with the distinction you draw here.

Regards,

Dave

David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810

-

---

From: Barney Wolff <[email-masked]>
Date: Wed, 3 Mar 1999 17:15 EST

> From: "Nelson, David" <[email-masked]>
> Date: Wed, 3 Mar 1999 16:44:55 -0500 
> 
> ...  However, when you

Well, I certainly don't disagree that a common interpretation of
attribute syntax and semantics is necessary, pairwise, on each hop.  But
forwarding is a different matter.  A proxy can decide on any basis
whatsoever - hash the user id, alternate for load sharing, time of day,
etc, without the slightest effect on interoperability.  The proxy's
algorithm must be understood by, and controlled by, its owner.  Neither
the NAS nor the eventual server needs to know it.  Of course, a proxy
that forwards a request to the wrong server is not very useful, so the
proxy needs a good model of reality.  I just don't see that as a
standards issue.

Regards,
Barney
-