Subject: Design Guidelines draft

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 12:35:37 +0200

Hi all, 

thanks for improving the document. 

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. 

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

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. 

The story from the RADEXT group, at least if I understood it correctly, was the extended attribute format, see http://datatracker.ietf.org/doc/draft-ietf-radext-extended-attributes/. This would solve the "exhaustion" issue. 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.). 

Additionally there are a few minor notes: 

a) What is a "service definition"? (see Section 2.3)

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?

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. 

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. 

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. 

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. 

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. 

Ciao
Hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Jul 2010 14:18:13 +0200

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

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

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

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

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

> 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 ab…

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

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

  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 d…

  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 correl…

  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 l…

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

  Alan DeKok.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 16:53:05 +0200

Hi Alan, 

thanks for the super-quick response. 

See inline. 

-------- Original-Nachricht --------
> Datum: Fri, 09 Jul 2010 14:18:13 +0200
> Von: Alan DeKok <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: [email-masked]
> Betreff: Re: Design Guidelines draft

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

OK. 

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

What I mean is that IPv6 address and IPv6 prefix is considered as a basic data type (even though it was standardized much later with RFC3162) although one can not really speak about widespread deployment given the deployment status of IPv6 in general. 

The tagging mechanism, described in Section 3.2.2, falls somewhere between the basic (Section 3.2.1) and complex (Section 3.2.3) data types -- based on the old draft version; version -15. 

That's what I meant with "drawing an arbitrary line". 

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

Interesting. 

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

Hmmm. 

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

Yup

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

But you understand what I mean. For example, with location information I could imagine that one uses a nice map and draw a circle there and then the software would provision that information into the database (in the right format for distribution within RADIUS). Now, assuming that an administrator would enter the data in the cryptic format defined by the RADIUS GEOPRIV RFC wouldn't probably work all that well. 

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

The problem is that it impacts the content of the document. 
Out of scope is what the editor and the group consider out of scope. 

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

These assumptions are not stated in the document. 

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

I already thought that you would say so. 

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Jul 2010 17:09:29 +0200

>> Section 3.2.1 into Section 2.1.

  After some review, I decided to simplify the text in 3.2.1 rather than
incorporating it into 2.1.  The sections have different purposes.  2.1
describes what the data types are.  3.2.1 describes why the data types
are confusing.

> What I mean is that IPv6 address and IPv6 prefix is considered as a basic data type (even though it was standardized much later with RFC3162) although one can not really speak about widespread depl…

  I think most widely used RADIUS servers support IPv6 transport, along
with the IPv6 data types.  Many switches and NAS equipment does, too.  I
don't think it's *used* that much, but they are deployed and inter-operable.

> The tagging mechanism, described in Section 3.2.2, falls somewhere between the basic (Section 3.2.1) and complex (Section 3.2.3) data types -- based on the old draft version; version -15. 

  Yes.  It's awkward, but is grandfathered in.

> That's what I meant with "drawing an arbitrary line". 

  It's RADIUS. :(  Nothing is simple.

>> the place to define them.

  If you have suggestions...

> But you understand what I mean. For example, with location information I could imagine that one uses a nice map and draw a circle there and then the software would provision that information into t…

  Sure.  Many systems support automatic IP address allocation, where the
data sent in a packet is created from an SQL procedure.  But I think the
general text still applies.  At some point, an administrator often has
to enter data.  Leveraging existing data entry methods is preferable to
creating unnecessary new ones.

> Out of scope is what the editor and the group consider out of scope. 

  I think a survey of server functionality is an admirable goal.  I
don't think that any survey would make a substantial difference in this
document.

> These assumptions are not stated in the document. 

  Stating them is not required, I think.

  Alan DeKok.