Subject: (radius) Proxy

From: Carl Rigney <[email-masked]>
Date: Mon, 6 Dec 1999 15:27:59 -0800 (PST)

I'm interested in hearing from people who've actually implemented Proxy
RADIUS or have operational experience with it.  Was the language in the
current draft (which passed working group last call in May with no
objections then) useful to you?  Can you make concrete suggestions as
to how to make it more useful to future implementers?  Have people
found any interoperability problems other than just cases where other
implementers didn't implement proxy or deliberately ignored the way
it's documented to work?

Having implemented proxy support myself, in Livingston's RADIUS server
2.1, the current text captures the best state of my knowledge as to the
things to best look out for.

As for forwarding servers manipulating the contents of access-accepts,
I recall us hashing that out at length nearly a year ago, and reaching
consensus that implementations WERE going to do it, so we might as well
make implementers aware that that sort of thing might happen.

--
Carl Rigney
RADIUS WG Chair
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Darran Potter" <[email-masked]>
Date: Tue, 7 Dec 1999 16:53:12 -0000

CiscoSecure NT doesnt manage re-transmissions... it does ignore
duplicate requests sent to it. So it depends on the NAS/up-stream
radius server as to what can happen.

IMHO. there are an infinite number of things a forwarding server could
be made to do.. many of which would probably be bad. We wouldnt 
want to see them all listed. Hence unless there is good reason to
include the paragraphs about re-transmissions I would remove them.

I personally dont think it adds anything to the RFC by its inclusion.

Darran
[email-masked]

----- Original Message ----- 
From: Carl Rigney <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 06, 1999 11:27 PM
Subject: (radius) Proxy

-

---

From: Barry James <[email-masked]>
Date: Tue, 7 Dec 1999 21:05:39 +0000 (GMT)

Carl,

	We have heavily developed and deployed a proxy RADIUS
infrastructure.  While I found it interesting to see mention of a proxy in
the current text, I'm not sure that the verbage was useful at all in 
architecting the service.  
	My primary concern would be that these passages do not do an
adequate job in presenting an all-inclusive understanding of what exactly
a RADIUS proxy is, what it does, or how it should (inter)operate and that
having this wording in the RFC will tend to pollute (or worse, confuse)
potential RADIUS architects and developers.  I feel that the RFC in this
situation should either fully explain and elaborate on the subject or
should point to an external reference that does the same.

Regards,
Barry

Barry L James            | Never doubt that a small group of
IP Systems Engineering   | thoughtful, committed citizens can
Level 3 Communications   | change the world.  Indeed, it's 
http://www.level3.com    | the only thing that ever has.
Member IEEE, AAAI        | #include <std_disclaimer>

-