Subject: Re: (radius) RADIUS ver 2

From: [email-masked]
Date: Mon, 27 Sep 1999 04:38:31 -0700 (PDT)

>> 
>> Actually there is a Radius 2 and it's documented at 
>> draft-ietf-radius-radius-v2-01.txt and it has nothing to do with Diameter.

Correct. There are a few new attributes documented since some of these had
become widely deployed. There is also support for Appletalk and EAP.

This is not an attempt to fix the protocol.

PatC
>
>I was asking about the status of this draft. From the naming
>convention it looks like  RADIUS working group draft. Could someone
>shed light on this?
>
>Thanks,
>-Gopal
>
>
>
>> 
>> And it sure would be nice to get a status update. Has the IESG reviewed it? 
>> Will they?
>> 
>> -
>> To unsubscribe, email [email-masked]' with
>> 'unsubscribe ietf-radius' in the body of the message.
>> 
>
>-
>To unsubscribe, email [email-masked]' with
>'unsubscribe ietf-radius' in the body of the message.
>
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Carl Rigney <[email-masked]>
Date: Wed, 29 Sep 1999 02:00:43 -0700 (PDT)

There is no such thing as RADIUS version 2; the
draft-ietf-radius-radius-v2-01.txt is for the advancement of RADIUS
from Proposed Draft to Draft Standard.  It's passed WG last call and is
ready for IETF last call, but needs a couple more documents to be
submitted along with it (the interoperability statement and some
guidelines on allocating attributes), which I'm working on.

The v2 is unfortunate, but that's how the Internet Drafts editor wanted
to name it.

--
Carl Rigney
RADIUS WG Chair
[email-masked]
-

---

From: [email-masked] (Patrice Calhoun)
Date: Wed, 29 Sep 1999 07:25:16 -0700

Somehow I missed the WG last call, must have been in stasis or something. I became aware
of the following text in the new document which I have objections with:

   A forwarding server may either perform its forwarding function in a
   pass through manner, where it sends retransmissions on as soon as it
   gets them, or it may take responsibility for retransmissions, for
   example in cases where the network link between forwarding and remote
   server has very different characteristics than the link between NAS
   and forwarding server.

   Extreme care should be used when implementing a proxy server that
   takes responsibility for retransmissions so that its retransmission
   policy is robust and scalable.

The text above is about as vague as one can possibly imagine, and it having *some*
intermediate nodes within a proxy chain perform their own retransmission, while
others do not *will* cause problems in the network. My opinion is that either this
document requires this functionality (where each node retransmits), or that only
the NAS does (as is the current protocol). Furthermore, a RADIUS server will not
be aware of the underlying links between the NAS and the forwarding servers, so I
don't quite understand how a server would know that this needs to be turned on.
Lastly, the last sentence makes it clear that the authors have issues with this
new statement, and "robust and scalable" is left up to the developer's imagination.

The whole premise behind RADIUS servers in the past was that they were largely 
stateless. I find it strange that moving the document to Draft Standard actually
changes the whole concept of RADIUS servers. My understanding of moving to Draft 
Standard is that no major protocol change should be introduced. I consider this 
very major, and it has never been proven to work in a large network.

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. The new draft now allows this. Is there a reason why
this never before functionality is now allowed in the new draft?

PatC

-