RE: Question regarding draft-ietf-radext-design-05.txt

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

Hannes Tschofenig writes...

> Even with the extended attribute document I could imagine that 
> the space gets consumed pretty quickly.

We have the option to assign different Private Enterprise Numbers to create
additional blocks of extended attributes.  That requires only IANA action
and not IETF protocol action, i.e. revised documents.

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

If the data is part of another protocols stream, e.g. EAP messages, then we
have the "opaque blob" exemption.  If the data fields need to be represented
as discrete elements that can be configured into the data-dictionary of a
RADIUS server, then one presumes that it is not part of another protocol
stream.
 
> 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.

That proposal was made in one of the early extended attributes drafts, and
was rejected by the RADEXT WG.  WG consensus says that approach is not
acceptable or interesting to the WG.  So, while technically you have a very
valid suggestion, it does not seem to gain traction in the RADEXT WG.
 
> 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).

The policy determination / enforcement mechanism of RADIUS servers is solely
a matter of implementation.  It might be implemented by means of delegation
/ consultation with some other service, via some other protocol.  Or it
might not.

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

I think readers likely know that.  The issue is whether extensions to the
RADIUS on-the-wire protocol should be designed to accommodate the
traditional, data-dictionary-driven RADIUS server, or not.  I think what we
are saying is that, while complex RADIUS server implementations exist,
RADIUS protocol enhancements should not be at the expense of the simple
implementations.
 
> I think that policy languages in AAA servers are getting more common
> today.

Perhaps.
 
> Finally, I would like to mention that RADIUS documents sometimes
> specify RADIUS/Diameter compatibility in a wrong fashion.

That's an issue we need to address, and get right.

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

Ah, the long-standing Diameter Application quagmire.  :-(

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

What do you suggest?

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

Please elaborate...

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

So, what you are suggesting is that the syntax and semantics of RADIUS
attributes are contextually dependent on some policy decision that is opaque
to the RADIUS client, proxies, etc?  I think that's a Very Bad Idea (tm) and
falls under the recommendation against polymorphic attribute design. 

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

No.  I don't think that individual drafts are noticed the IETF New Work list
(maybe I'm wrong) so it would only come to the attention of other SDOs via
the efforts of overlapping participants.



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