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

[Alan DeKok <aland@deployingradius.com>]

Avi Lior wrote:
> 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.

  The guidelines document says "SDOs do whatever the heck they want".

  If this isn't clear, we can put it in 50pt blinking neon text.

> 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"

  Hmm... I'll check the revision control to see what happened to that.

> 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.

  I'll run away from *that* discussion.  The document is "guidelines",
not "redesigning RADIUS".  Some later document will recommend a better
solution.

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

  That recommendation was in the document, and was removed after RADEXT
discussions.  It can't really be added back.

> 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?

  I dunno.  The document doesn't add new attributes.  It suggests how to
get the most out of the existing RADIUS functionality.

> 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?

 It's a BCP, not a "this is what we SHOULD have done".

> 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.

  Great!  Write an IETF draft, or an SDO specification.  Either way, the
guidelines document isn't affected.

> 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.

  Hmm... it might not be perfect, but it does make some kind of sense.
I welcome suggestions for replacement text.

> 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.

  Please suggest better text.  The existing text has been word-smithed
nearly to death.  I would like to see someone else suggest new text, so
I don't get blamed for issues with the document.

> I agree with this --- But the problem is that we don't know what is RADIUS.  So lets get that defined first.

  Suggest some text.

  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/>