Subject: Re: (radius) RADIUS proxy (fwd)

From: MegaZone <[email-masked]>
Date: Tue, 16 Mar 1999 15:10:32 -0800 (PST)

Once upon a time Alan DeKok shaped the electrons to say...
>  A normal RADIUS client doesn't need a Proxy-State to match
>Access-Accept's to Access-Request's.  If a RADIUS server is proxying a

This isn't the trouble at hand - a normal client-server setup doesn't have 
loop potential either.

The issue isn't matching the reply to the request - the trouble is knowing
that a loop exists.  Proxy A talks to Proxy B which talks to Proxy C - which
talks to Proxy A.  Frankly I don't believe there is any foolproof method
to detect loops.  VSA may be the best, as I agree with the sentiment that
any server that arbitrarily removes VSAs isn't well behaved.  But Proxy-State
can also be useful.  Not all servers remove it, personally I think that
even those that can should NOT do so by default - but make it an option
to be used ONLY when required.  As in when talking to a server that does
not understand Proxy-State.  Don't force poor behavior by implementation.
I think being able to talk to legacy servers is good - but don't lower the
bar when it doesn't have to be.  There is the *chance* of another proxy
adding a clone Proxy-State.  But I think the odds of a proxy server that
just happens to be in a loop condition with another server just happens to
insert a Proxy-State which happens to be a current value on the first server
is sufficiently low.  Of course, I'd also hope that the humans involved
would take precautions to avoid loops as best they can - while acknowleding
that, especially in complex proxy meshes, they will happen.

Proxy-State does, or at lease, should, make it easier to match replies to
requests - but I agree that other methods should be able to handle that.
Maybe I'm misunderstanding, but my impression is that the client-server
relationship DOES still exist between proxy servers.  And that the
reply MUST come from the same IP/port tuple that the request was sent to.
Which would mean the standard NAS-server style matching still works.

-MZ
-- 
-=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
<URL:mailto:[email-masked]> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
<URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Mar 1999 09:05:34 -0500

MegaZone <[email-masked]> wrote:
> to detect loops.

  From recent discussion, I doubt there's *any* method for detecting
loops, as too many servers play incompatible games with Proxy-State.

> VSA may be the best, as I agree with the sentiment that any server
> that arbitrarily removes VSAs isn't well behaved.

  Certain implementation decisions make it easier for the server to
drop attributes it doesn't understand.  e.g. An incoming RADIUS
request is parsed into machine-specific data structures (VALUE_PAIRs),
and the proxied packet is parsed from those data structures to RADIUS
attributes.

  So any attribute which doesn't make it into a structure doesn't get
proxied.  This behaviour is probably incorrect, and proxies most
likely should copy RADIUS attributes "raw", if at all possible.

  I guess I'm being pedantic here in coming up with a lot of "what
if" situations, and pointing out implementation problems.  But I like
to be clear on exactly what's going on and why, before making an
informed decision.

> Which would mean the standard NAS-server style matching still works.

  I believe so.

  Alan DeKok.
-