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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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 <Hannes.Tschofenig@gmx.net>
> To: 	radiusext@ops.ietf.org
> 
> 
> 
> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>