[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
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
>radiusext-request@ops.ietf.org 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>