Subject: Re: (radius) RADIUS ver 2

From: Carl Rigney <[email-masked]>
Date: Mon, 11 Oct 1999 23:29:15 -0700 (PDT)

it having *some* intermediate nodes within a proxy chain
	perform their own retransmission, while others do not *will*
	cause problems in the network.

Why?  Either you pass things through as you get them, or you take
responsibility and use your own retransmit policy because you know best
(but keeping in mind that if its an access-request, you have a limited
time budget to work with).  It seems a very reasonable thing to have
implementations experiment with, and if someone comes up with a method
that is superior, they can publish it and people can adopt that.  I
would love to see people do some real testing and verification of
retransmit strategies and publish ideas on the topic, the way Van
Jacobson did with TCP windowing.

In most cases Proxy shouldn't need more than 2 hops anyway (I can see
three, but more than that strikes me as likely to be the result of poor
network design).

We have lots of people using Proxy with no reported problems.  I'd be very
interested in hearing from anyone who has operational experience with
RADIUS proxy and is running into any problems.

	The whole premise behind RADIUS servers in the past was that
	they were largely stateless.

And RADIUS servers in the past didn't do proxy.  If you want a
proxy-capable RADIUS server to be able to forward requests to older
RADIUS servers that don't do Proxy (that is, that don't copy the
Proxy-State attribute from request to response), then the forwarding
server has to cache any existing Proxy-States and reattach them when
the reply comes back.  We may both agree that this is not an ideal
thing to do, but if done properly it works very well, and allows
interoperability with existing RADIUS implementations without requiring
that everyone upgrade at once.

Also, RADIUS accounting seems to require maintaining state when doing
proxy, unless someone's come up with a stateless way of dealing with
the Response Authenticator (if so, I'd love to hear about it!).

And many implementers who are dealing with high volumes of RADIUS
accounting packets may wish to cache them securely on an intermediate
RADIUS server and ack them to the NAS, to free up the (typically very
small) buffer memory on the NAS in the case of extended outages on the
network or final accounting server.

	One more comment. In the past it has been made very clear that
	an empty attribute (length = 2), is invalid and not supported
	in the RADIUS protocol. For this reason we had to change the
	EAP draft.

Ah!  I wasn't aware the EAP draft changed so that EAP-Start is no longer
zero length.  In that case I can change the RADIUS Extensions draft
attribute 79 to replace

> Length 
> >= 3 (EAP packet enclosed)
>  = 2  (EAP-Start message)

With simply:

Length 
>= 3

So that it's consistent with the draft-ietf-radius-radius-v2-01.txt
requirement that all attribute lengths be 3 or greater.  Excellent.  If
you see anywhere else in the 3 drafts where an empty attribute is
permitted, please point it out to me; there are not supposed to be
any.

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 12 Oct 1999 05:47:17 -0700

>zero length.  

It didn't change. The draft hasn't been updated since it was incorporated
in RADIUS extensions. 

-

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 12 Oct 1999 20:44:17 -0700

>	EAP draft

Is there any reason for not allowing empty attribute (length = 2)? There
could  be several
benefits if we have this flexibility. 

Thanks
Gopal

Gopal Dommety
Cisco Systems

-