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

From: "David B. Nelson" <[email-masked]>
Date: Thu, 18 Sep 2008 14:37:13 -0400

Hannes Tschofenig writes...

> Could you please post this mail? For some reason, it does not reach the
> mailing list.
> 
> -------- Original Message --------
> Subject: 	Question regarding draft-ietf-radext-design-05.txt.
> Date: 	Wed, 17 Sep 2008 22:22:30 +0300
> From: 	Hannes Tschofenig <[email-masked]>
> To: 	[email-masked]
> 
> 
> 
> I would like to discuss one specific aspect of
> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt.
> 
> 2.1.3.  Complex Attribute Usage
> 
> I believe that there are two types of complex attributes that need to
> get differentiated.
> There is the (flat) complex attribute that can be represented now with
> http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-
> 04.txt.
> 
> Then, there are (nested) complex attributes that
> draft-ietf-radext-extended-attributes-04.txt does not allow. This is,
> however, possible with Diameter.
> 
>   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.
> 
> Until recently it wasn't really an option to put everything into a
> separate document.
> Even with the extended attribute document I could imagine that the space
> gets consumed pretty quickly.
> 
> 
> 
>      * 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.
> 
>      * 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.
> 
>   One of the fundamental goals of the RADIUS protocol design was to
>   allow RADIUS servers to be configured to support new attributes
>   without requiring server code changes. RADIUS server implementations
>   typically use provide support for basic data types, and define
>   attributes in a data dictionary.  This architecture enables a new
>   attribute to be supported by the addition of a dictionary entry,
>   without requiring RADIUS server code changes.
> 
> 
> 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
> 
> 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).
> 
> 
> 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.
> 
> 
>   Code changes can also be required in policy management and in the
>   RADIUS server's receive path.  These changes are due to limitations
>   in RADIUS server policy languages, which typically only provide for
>   limited operations (such as comparisons or arithmetic operations) on
>   the basic data types.  Many existing RADIUS policy languages
>   typically are not capable of parsing sub-elements, or providing
>   sophisticated matching functionality.
> 
> 
> 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).
> 
> 
> 
> Finally, I would like to mention that RADIUS documents sometimes specify
> RADIUS/Diameter compatibility in a wrong fashion.
> For example, there are a number of RADIUS documents that indicate that
> the corresponding Diameter AVPs have the M-bit set.
> This cannot be possible since this would require a new Diameter
> application to be specified. I am not even sure that it is always the
> right way to put such a section in a RADIUS document when they authors
> do not envision Diameter to be used in their specific environment.
> 
> 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.
> 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.
> There are, without doubt, more and less secure languages.
> 
> 
> Btw, has the draft been sent to other SDOs for review?
> 
> 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, 19 Sep 2008 08:58:10 +0200

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

>> have far more data types available.

  Nice idea, but this is RADIUS.  We can't change it at this point.

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

>> that there is some business logic that needs to be executed).

  That happens, but it's independent of RADIUS dictionaries.

>> just boxes where one could have used SQL instead of the RADIUS protocol

  The original servers didn't even use SQL...

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

>> RADIUS/Diameter compatibility in a wrong fashion.

  Are there any changes required to the design guidelines document?  Can
you offer suggested text?

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

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

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

>> Btw, has the draft been sent to other SDOs for review?

  Suggestions?

  Alan DeKok.