Re: Design Guidelines draft

[Alan DeKok <aland@deployingradius.com>]

Hannes Tschofenig wrote:
> I had a brief look again at the latest version of the design guidelines draft and noticed 2 points that I would like to highlight: 
> 
> 1) Repetition
> 
> Section 2.1 lists the basic data types. Section 3.2.1 lists them again. And so does Appendix A.1.1.
> 
> I would argue that we should only have them once listed in the document (at least I would argue to get rid of A.1.1). Appendix A in general repeats what was said in the previous section again. Appendix B is good since it shows some of the examples. 

  I agree.  I'll delete the list in A.1.1, and incorporate the text from
Section 3.2.1 into Section 2.1.

> The line drawn between the basic and the complex data types is still arbitrarily, which leaves a bad taste behind. 

  I'm not sure how it's arbitrary.  The basic data types are "integer",
"Ip address", etc.  The tagging mechanism is allowed because it's widely
used.  Any grouping, nesting, structed types are "complex".

> 2) Inconsistent story
> 
> To avoid complex attributes the document argues to split them. But then the document furthermore argues that the attribute code space is going to be exhausted pretty soon. 

  Yes.  It's hoped that the attribute space exhaustion will be fixed in
a future spec.  Given the current rate of assignment, I think we have a
few years left before the RFC space is full.

> However, it does not nicely fit in the story of basic vs. complex
attributes since the extended attribute format is a complex attribute
that by definition in the document has to be avoided at all cost
(because of security vulnerabilities, etc.).

  No.  The document RECOMMENDS that complex types be avoided.  It allows
later documents to update this one.  If the WG decides that the extended
format is an allowable "complex" type, then *nothing* in this document
forbids that.

  I'll repeat, because that point has come up many, many, times.
NOTHING in this document forbids or prohibits the WG from defining the
extended attributes to be of complex types.

> Additionally there are a few minor notes: 
> 
> a) What is a "service definition"? (see Section 2.3)

  A "service being provisioned".

> A reference to an example would help to understand what is actually meant (and what isn't). The term "service" is so generic that it has to lead to confusion. For example, is the recently proposed SAML messaging work over RADIUS a negative example for this?

  The existing RFCs are vague on what "services" mean.  This spec isn't
the place to define them.

> b) Section 3.2.3: 
> 
> "
>       * it is easier for the user to enter the data as well-known
>         types, rather than complex structures;
> "
> 
> please replace the term "user" with something else, particularly since the rest of the document talks about the user in the sense of the person gaining access to the network. here we are talking about the person doing the system administration. 

  OK.  That could be "an administrator" instead of "a user"

> c) Section 3.2.3: A general comment
> 
> With the following bullets I would like to have a sentence added that this is very implementation specific: 
>
> "
>       * it is easier for the user to enter the data as well-known
>         types, rather than complex structures;
> 
>       * it enables additional error checking by leveraging the
>         parsing and validation routines for well-known types;
> 
>       * it simplifies implementations by eliminating special-case
>         attribute-specific parsing.
> 
> "
> 
> Regarding the first item: It depends how you provision the data. if you type them with an ASCII editor then I fully agree. If you have tools then I disagree. For larger systems you are not using an ASCII editor, IMHO. 

  The data can be entered in ASCII in a text editor, into a form field
of a GUI, etc.  The data does not magically "know" what value it should
have.  That information has to come from somewhere.  That "somewhere"
*always* leads back to a human being.

> Regarding the second item: It depends when you do the error checking. If you do it as post-processing (for example, when the data ends up in the database) then there isn't an issue at all. if you do it in real-time when you get the data provided then you will in many cases have to have a more sophisticated policy language; the capabilities of the policy language has never been clearly described nor investigated as part of a survey of available implementations. 

  That investigation is out of scope for this document.

  And even when the data comes from a database, the RADIUS server nearly
always does some parsing of it.  i.e. the DB can do syntax checking on
IP addresses, but the SQL queries can return the IPs as either a
"native" 4 octet blob, or as a string.  When the SQL query returns a
string, the RADIUS server needs to parse it.

> Regarding item three: I agree with this item to some extend but splitting attributes into multiple attributes (or even multiple messages, as suggested in the text) requires some mechanism to correlate them. This also requires code and potentially state to be maintained. 

  Potentially.  However, most RADIUS implementations should already have
the ability to send multiple attributes at once.  That functionality can
be leveraged to send "logically" correlated attributes.

> I would encourage the group to investigate the existing RADIUS server implementation features (independently of the document; certainly not blocking the progress of the document) because it could lead to interesting insights. I would also be in favor of suggesting that people think about how they are going to process attributes (on the sending and on the receiving side and what the required code changes are). Being explicit about these aspects would improve the quality of the specification IMHO. 

  That's a great idea.  I'm not going to do it, however.

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