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

[Alan DeKok <aland@deployingradius.com>]

Joseph Salowey (jsalowey) wrote:
> A. Section 2.1.3  
> 
> I did not find the discussion of complex attributes very compelling.
> Its not clear to me what the difference between string and complex
> attribute is.  If your RADIUS server supports string then it seems that
> it would be possible to support a complex attribute without requiring a
> "code change".  

  It depends on what you mean by "support".

  There is no question that a RADIUS server can *transport* any complex
attribute if the attribute is treated as type "string".  However, having
the RADIUS server parse that attribute requires much more work.

  Perhaps a better argument is to ask "why?".  i.e. Why is a data
structure being sent when the contents could have been broken out into
separate attributes with standard data types?

  The document tries to suggest that where possible, complex attributes
should be replaced by attributes with standard data types.  Where that
is not possible, complex attributes could be used.

> B. Section 2.1.4
> 
> I'm not really sure what this section is trying to accomplish.  It seems
> to be a lot about deployment guidelines instead of design guidelines.
> I'm also not convinced that the use of complex attributes makes things
> less secure.  It does not seem this section belongs in this document. 

  Using complex attributes does not make things less secure.  *Code
changes* make things less secure.

  The intent of this section is to explain some of the reasons behind
the recommendations, rather than to have them appear out of thin air.

> C. Section 5
> 
> This section references section 2.1.4, however it does not seem there is
> anything actionable for a protocol document to do with section 2.1.4. 

  I think the reference should be to 2.1.3.

> D. Section A.2.2
> 
> Since I did not agree with the motivation for section 2.1.3, I don't
> find this section compelling. 

  This is one point where I strongly disagree.  It can be summarized as
"keep things simple".

  Would you counter this section by suggesting it's a *good* idea to
have complex attributes, where standard ones would do just as well?  If
so, why?

> E. Section A.2.1
> 
> I don't see how defining a polymorphic attribute as multiple attributes
> helps.  I'm probably missing something, do you have an example? 

 See Section 3.2 for a larger explanation.  In short:

- Attribute X means "integer", unless there is another attribute Y in
the packet, in which case Attribute X means "mac address"

  Both the size and contents of the attribute changes.  There's really
no good reason.  Instead, two standard attributes can be used, with no
magical meanings.

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