Re: "Last Look" at the RADIUS Design Guidelines document

[Avi Lior <avi@bridgewatersystems.com>]

On 06-01-2010, at 09:57 , Alan DeKok wrote:

> Avi Lior wrote:
>> I dont agree with that.  You should not make a judgement call about my application layer.  A complex attribute embedded in a VSA or a String does not make RADIUS layer complex!!!
> 
>  The document states *clearly* that transporting complex attributes is
> fine, so long as it is opaque to RADIUS.
Great!!!! But this also creates confusion.  Because what is RADIUS.....

IETF publishes a document that says its BAD to do something if it is RADIUS and not bad if it is not RADIUS --- then it better define what is meant by RADIUS.  Otherwise I have to live with the debate for the rest of my SDO life.

> 
>  If the attributes are *not* opaque to RADIUS, then all of my previous
> comments about complexity apply.
> 
>> You are asserting that grouping of attributes together adds complexity and I am saying that that is not neccessarily true.
> 
>  I'm pretty sure I never said that.
well... complex types is grouping of attributes and by that nexus I am pretty sure you are saying that.

> 
>> I think you should let the Designer of the "Application" decide - or do a better job talking about design practices of the Application layer.  I rather we keep silence about practices at the application layer.
> 
>  The document *explicitly* states that transport of opaque data (i.e.
> application data) is permitted.
> 
>  I am already doing what you request.  Please read the document.

So I am again....

Issue 1: we are missing some text in the last paragraph of section 2.0  RADIUS Data Model

"The similarity between
   attribute formats has enabled implementations to leverage common
   parsing functionality, although in some cases the attributes in the"

Issue 2:

2.1.2  Tagging

" For these reasons, the tagging scheme described in RFC 2868 is NOT
   RECOMMENDED for use as a generic grouping mechanism."

Great and I agree!!!  So what is recommended??? Solve the problem.

Complex Attribute Usage is one way to solve this problem...We should state that.


Issue 2.1.3

The entire language of this section is about AAA application layer vs parsing by AAA transport layer.

User data entry is application layer
Additional error checking is application layer
Simplifies implementation is by appliation layer

" One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes."

So how do i add a QoS attributes to RADIUS without  code changes?

we need to think about how we use RADIUS today vs what we did in the past.  This is after all a Best Current Practice document, right?

If i am sending 6 QoS profiles over RADIUS with each QoS profile consisting of several attributes then i need grouping of some sorts to group the classifer with the relevant qos attributes.

IPFilterRule is a complex type....

The message you are sending in section 2.1.3 makes no sense.

So  after reading the document - I still have a problem with 2.1.3


Next ....

"On the RADIUS client, code changes are typically required in order to
   implement a new attribute.  The RADIUS client typically has to
   compose the attribute dynamically when sending.  When receiving, a
   RADIUS client needs to be able to parse the attribute and carry out
   the requested service.  As a result, a detailed understanding of the
   new attribute is required on clients, and data dictionaries are less
   useful on clients than on servers."

The par. above make no sense.  It is equally true for the server to have to parse attributes in an access-request to carryout its authentication and more so its authorization.  In the old days i would agree with you but now????? No way.

Same is true for the next paragraph.....

This section simply refuses to recognize what is really going on in RADIUS land.


"Given these limitations, the introduction of complex attributes can
   require code changes on the RADIUS server which would be unnecessary
   if basic data types had been used instead.  "

Nonsense.  So having a NAS sending its capabiities to the RADIUS server as a set of standard attributes will not require code changes?  The RADIUS server will happily understand them and be able to take the correct action(s) ????

So while I almost believe you when I read your assertion in the email...when I read the text all goes out the window.

We better define what you mean by RADIUS.....  Because section 2.1.3 is all about Application Layer stuff.
 

> 
>> I think the push back is based on the fact that we are disagreeing on the application.  If we rely on the RADIUS layer to parse the attributes then yes it is complex.  But this is not about the RADIUS layer.  And the use of these grouped AVPs is actually reduces complexity.
> 
>  The document and this list is about RADIUS.  I have no comments on
> non-RADIUS application data.  It now seems that your comments are not
> about RADIUS, and therefore are either already addressed in the
> document, or are irrelevant to RADIUS.
> 
>  i.e. If this isn't about RADIUS, then the discussion can stop now.
> 
I agree with this --- But the problem is that we don't know what is RADIUS.  So lets get that defined first.

Then we can take all non-RADIUS text out of the document.

>  Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>