Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 25 Dec 2008 15:24:22 +0200

Hi Alan, 

also sorry that I did not reply to this mail earlier.  

>>>      * it is easier for the user to enter the data as well-known
>>>        types, rather than complex structures;
>>>
>>> I believe this text shouldn't really say "user". Even on the AAA 
>>> server (to which this text is most likely pointing to) I 
>think it is 
>>> worth pointing out that this depends a lot on where the data comes 
>>> from; often it does not come from a human.
>
>  Sure.  That could say:
>
>  * it is easier for the data to be managed as well-known types...

I guess we all agree that it would be nice to have only well-known data
types. 
The problem unfortunately is that the extended attributes draft does not
allow this to happen because of it's restricted treatement of complex
attributes. Even we some of the DIME documents we have today we run into a
lot of problems. 

>
>>>      * it enables additional error checking by leveraging the
>>>        parsing and validation routines for well-known types;
>>>
>>> If you are truely serious about this issue then one should 
>replicate 
>>> the Diameter mechanisms where you can group AVPs arbitrarily and 
>>> where you have far more data types available.
>
>  Nice idea, but this is RADIUS.  We can't change it at this point.

Well. RADIUS is a protocol and protocols seem to change over time. We see
this also with RADIUS. 
Recent example: TCP and TLS extensions for RADIUS

>
>>> I would like to discuss this statement a bit. It makes an 
>assumption 
>>> about the way how a RADIUS server works that might not be how it is 
>>> always being used today. It indicates that a RADIUS server works 
>>> roughly in the following way:
>>>
>>> a) Receive attributes (e.g., attribute foobar)
>>> b) Formulate a query based on the received attributes (e.g., select 
>>> foobar from tables where user-id=X)
>>> c) Return result from previous query
>
>  No.  It assumes that policies inside of the RADIUS server 
>are managed by attribute *name*, rather than on-the-wire number.

I am not sure how this relates to my statement. 

>
>>> This ignores that there might be more complex processing 
>going on in 
>>> the RADIUS server, for example that other protocols need to get 
>>> invoked to get the result (e.g., attributes Y require LDAP to fetch 
>>> results from server X while other mechanisms may be consulted to 
>>> obtain the necessary information related to attributes Z), 
>that there 
>>> is some business logic that needs to be executed).
>
>  That happens, but it's independent of RADIUS dictionaries.
>
>>> I would at least like to relax this statement a bit and acknowledge 
>>> the fact that RADIUS servers are a bit more complex today than just 
>>> boxes where one could have used SQL instead of the RADIUS protocol 
>>> right away.
>
>  The original servers didn't even use SQL...
>
>>> I think that policy languages in AAA servers are getting 
>more common 
>>> today.
>>> During the Diameter interop I have seen a lot of vendors 
>using quite 
>>> sophisticated policy languages and their boxes supported (in almost 
>>> all
>>> cases) not only Diameter but also RADIUS (and other protocols).
>
>  Yes.  Some RADIUS servers also support complex attribute 
>decoding through simple scripting languages.  But this has not 
>been historically wide-spread.

These assumptions have been built-into the draft and it would be good to be
explicit what type of RADIUS server you are talking about when you argue
that complex attributes lead to implementation, deployment and security
problems. This may very well be true be true for some of these servers but
certainly not true for many others. Maybe these older servers don't even
care about the functionality we are specifying today. 

>
>>> Finally, I would like to mention that RADIUS documents sometimes 
>>> specify RADIUS/Diameter compatibility in a wrong fashion.
>
>  Are there any changes required to the design guidelines 
>document?  Can you offer suggested text?

My immediate suggestion: Don't put a RADIUS / Diameter compatibility
considerations section into the document as it is almost always wrong. 

>
>>> The following paragraph (and a lot of related text) is 
>related to the 
>>> aspect of policy languages:
>>>
>>>   However, some standard attributes do not follow this format.
>>>   Attributes that use sub-fields instead of using a basic 
>data type are
>>>   known as "complex attributes".  As described below, the 
>definition of
>>>   complex attributes can lead to interoperability and deployment
>>>   issues, so they need to be introduced with care.
>>>
>>> It somewhat depends on how the policy language works and what you 
>>> expect the policy language todo.
>
> "Can lead ...".  The text is describing common practices and 
>deployments.  The only reason to change the text is if those 
>practices are not, in fact, in common use.

But these type of statements are used against draft authors who decided to
pick a different format and then we have all these discussions. 

I think it would be useful to provide a bit more context, as argued a few
paragraphs above. 

>
>>> If you also assume that the policy language is not only 
>used to deal 
>>> with the business logic but also with decoding and encoding of 
>>> attribute content then one could deal with a number of 
>>> interoperability and security issues with the choice of language.
>
>  This is really splitting hairs over what "code" is.  
>Assembler is code.  Policy languages are (not?) code.  Java is 
>intermediate...

The type of language really matters a lot when it comes to security issues.
There are certainly languages where buffer overflows and other issues are
more common than in other languages. It is also a difference whether a
developer has to write code in the scripting language of the AAA server or
whether the core part of the server has to be changed. 

>
>  In any case, *some* logic has to be updated for complex attributes.

As I mentioned in the mail to David I argue that for some of the "customer
groups" there is code at the level of the scripting language necessary
anyway (for almost all of the documents that get produced). Hence, I
provided the comparison to SQL in my previous mail by saying that RADIUS is
different to the initial versions of SQL databases in the sense that new
functionality requires often a bit of new code at the AAA server. Even SQL
has evolved over time and some of these database systems also allow some
form of scripting (e.g., via PL/SQL) 

>
>>> Btw, has the draft been sent to other SDOs for review?
>
>  Suggestions?
Almost all the major SDOs have to deal with RADIUS in some form:
Wimax Forum, Broadband Forum, 3GPP, 3GPP2, CableLabs

Ciao
Hannes

>
>  Alan DeKok.
>
>--
>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/>
>

--
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: Sat, 27 Dec 2008 17:05:19 +0100

> care about the functionality we are specifying today. 

  That's a good point.

  Can you suggest updated text for the draft?

> considerations section into the document as it is almost always wrong. 

  I'll have to ask the chairs about this...

> I think it would be useful to provide a bit more context, as argued a few

  Ok.  We should be able to make it clearer that the opinions against
complex attributes are SHOULD NOT.

> Wimax Forum, Broadband Forum, 3GPP, 3GPP2, CableLabs

  I think the chairs should ask for official statements from the other SDOs.

  Alan DeKok.

---

From: "D. B. Nelson" <[email-masked]>
Date: Sat, 27 Dec 2008 15:44:13 -0500

Alan DeKok writes...

>> But these type of statements are used against draft authors who
>> decided to pick a different format and then we have all these
>> discussions. 
>> 
>> I think it would be useful to provide a bit more context, as 
>> argued a few paragraphs above. 
>
>  Ok.  We should be able to make it clearer that the opinions
> against complex attributes are SHOULD NOT.

Hmmm...  Two thoughts on this:

(1) Since the Design Guidelines are to be a BCP, guidance about design
choices, short of a major security flaw or a redesign of the RADIUS base
protocol, will end up being a SHOULD or SHOULD NOT.  MUST and MUST NOT will
be rare.

(2) At some level, RADIUS Design Guidelines will likely be as popular with
certain developers as corporate coding style guidelines.  :-)  That's the
nature of the beast.  Having said that, if the guidelines value everyone's
individual design styles equally, then the guidelines serve no purpose.  The
value in creating a RECOMMENED design style is in achieving a certain level
of uniformity.  There is a fine balance to be struck between standardization
and creative expression.

---

From: "D. B. Nelson" <[email-masked]>
Date: Sat, 27 Dec 2008 16:21:29 -0500

Alan DeKok writes...

>  I'll have to ask the chairs about this...

<Chair Hat = on>

I don't think it's OK to simply "punt" on Diameter interoperability
considerations in RADIUS extensions work.  It's in the RADEXT charter, for
good reason.

I agree that the boilerplate text we've been using recently is flawed.  It's
not enough to effectively say "just follow NASreq".  There are a number of
issues to address, with complex AVP encoding and Application IDs being top
of mind.  It seems to me that the authors so RFC 4005 thought about
importing all of the RADIUS attributes that existed at the time that
document was published under the NASreq Application ID, but not about future
RADIUS extensions.  The whole mandatory attributes vs. new application IDs
thing is a major headache that, IMHO, DIME needs to solve.

We need tome assistance from folks in DIME, and we may need them to create
an RFC 4005bis, or some such.

I don't think we can simply omit discussing Diameter compatibly and
interoperability.

If there is a good reason why Diameter interoperability (ease of gateway) is
not required for a given application area, then we can simply say that in
the document -- don't bother trying to import these attributes into
Diameter.

<Chair Hat = off>