[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design Guidelines draft
Hi Alan,
thanks for the super-quick response.
See inline.
-------- Original-Nachricht --------
> Datum: Fri, 09 Jul 2010 14:18:13 +0200
> Von: Alan DeKok <aland@deployingradius.com>
> An: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> CC: radiusext@ops.ietf.org
> 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
> >
> > 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.
OK.
>
> > 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".
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.
>
> 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.
>
Interesting.
> > 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.
Hmmm.
>
> > 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"
Yup
>
> > 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.
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.
>
> That investigation is out of scope for this document.
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.
>
> 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.
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.
>
> That's a great idea. I'm not going to do it, however.
I already thought that you would say so.
Ciao
Hannes
>
> 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/>