[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question regarding draft-ietf-radext-design-05.txt
I noticed that I did not reply to these messages.
>> If you are truely serious about this issue then one should replicate
>> the Diameter mechanisms where you can group AVPs arbitrarily
>> 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),
>> 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.
While this is indeed an aspect of implementation there seem to be aspects
that impact the larger topic of how extensibility is perceived to work.
>> 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 it is not a question of simple or complex implementation.
The main issue is what the specific customers want. AAA servers are used by
different clusters of customers (different types of enterprises, WLAN
hotspots, universities, ISPs, cellular operators, etc). These customers have
different needs but the guidelines do not acknowledge that there are
different classes of customers and hence the design guidelines are often
applied without considering these aspects. I believe I can say that because
I was a victim of "strictly applying" the guidelines as they are, despite
the examples provided in the document on EAP etc.
>> I think that policy languages in AAA servers are getting more common
Would be worth investigating what folks develop today.
>> 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
>> 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?
Based on the discussion we had at the AAA doctors meeting I will think about
some way forward.
>> 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.
The above statement makes the assumption that the parsing happens in some
C-alike language that was used to implement the entire RADIUS server.
There are indeed issues when you touch this code.
However, most AAA servers have an abstract language they use for handling of
msg processing. This language is typically not C and written in a way that
it does not lead to security issues. As such, even additional parsing that
has to be implemented it does not lead to any interoperability or security
problems. Furthermore, as I argued above, since RADIUS usage today requires
more interaction the same language is used for the other processing and when
new functionality is added new code is being added.
>> 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.
No, my argument is different. I believe that the argument that complex
attributes lead to interoperability, deployment and security issues as
stated in the draft is incorrect and can of course happen from certain
implementation choices. Most AAA server do not have these issues as they are
providing an abstract language for the developer for business logic,
parsing, msg handling, etc.
>> 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.
Maybe it would have been good to get some feedback from organizations that
typically mess around with RADIUS protocols.
>to unsubscribe send a message to
>firstname.lastname@example.org with the word 'unsubscribe' in
>a single line as the message text body.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.