[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
>>
>> And even in the extended document i did not want to extend the attribute in the sense of COmplex Types. The working group did. All we were trying to do is extended the attribute type space beyond 256.
>
> ... and add a new grouping mechanism
>
> ... and add a mechanism to allow attributes longer than 253 octets.
>
> http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt
>
> That's from 2007, before it was a WG draft. I can read, too.
So draft http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-00.txt
dated Nov 25, 2003 Did not have tagging or anyting like that. That was document laid dormanent until October 19, 2006
when http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-01.txt came out with tagging added.
This if you can recall was because of all sudden the group decided that they wanted this work and they asked us to extended with grouping. This is when Glen was added and he became the editor adding stuff that the WG asked for.
You maybe capable of reading but that isn't enough I am afraid. You should know the history around this document.
>
> Avi Lior, January 6:
>>>> I think it would be worth while to define the RADIUS model first.
>>>> Not the old RADIUS model but rather the one that we are all living
>>>> with today. That model is not really different then Diameter.
>
> 40% (or more) of current RADIUS deployments would disagree.
Good so 60% do and I think and other think that you should address the majority cases No?
On 14-01-2010, at 02:50 , Alan DeKok wrote:
> Avi Lior wrote:
>> I am not proposing to redefine RADIUS. Please show me where I am doing that WRT to this document.
>
> You are *demanding* that the traditional RADIUS model be removed from
> the document. You have stated that it is no longer relevant:
Never!!!! I was requesting that you define the model you are using. And because the document does talk about applications. Just define it. At the root of this is the following statement:
From Guidelines "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.
I dont understand how adding a new attribute of an existing type to an Access-Request does not require code changes in the RADIUS server? The RADIUS server has to process this attribute no? It has to make policy decision based on this attribute no?
Next you talk about the following:
"On the RADIUS client, code changes are typically required in order to
implement a new attribute. The RADIUS client typically has to
compose the attribute dynamically when sending. When receiving, a
RADIUS client needs to be able to parse the attribute and carry out
the requested service. As a result, a detailed understanding of the
new attribute is required on clients, and data dictionaries are less
useful on clients than on servers."
But this confuses me.... I think that Clients and Servers have to do the same work. I think that both require a detailed understanding of a new attribute.
I do agree that Servers get attributes from a database when composing a response and certainly that is true for older generations of server. But today and going forward this is not true. More often now servers have to compose their response by computing the attributes dynamically.
Similarly, in the historic use of RADIUS servers, we got username password and all we did was look this up in a database. Today typically we get service request attributes, we get hints of location etc... the Server has to parse these and understand them.
So I agree the goal was -- but it is no longer relevant in 60% of the cases. And really what are you writing this BCP for - isnt it to guide new work? And is this new work guiding to be relevant to the 40% or the 60% of the market space?
I have been asking RADEXT to consider this.
>
>> Take a look at my comments and comments made by other folks and stick to those topics. That is if you want to make progress.
>
> I have seen *no* relevant argument for removing discussions on
> attribute design from the design guidelines document. The main
> rationale put forward is "it will make my life difficult in an SDO".
> (Which also puts paid to the argument that "everyone will ignore it")
No I think you are being a little unfair. The main rational is that you are making claims that complex attributes are bad and insecure and you are basing on erroneous model that caters to traditional/old deployments that compose 40% of the market (your number). This perhaps is where you work.
I think you should cater to or at least recognize the other 60% of the market where this model is not valid anymore. This is where I work at the SDOs.
By at least explicitly documenting the model you are using....then we can judge the applicability of this document. Right now it is not obvious.
As a minimum be explicit about the model you are catering to.
Why my life would difficult at the SDO is that I would have to explain this to folks and I'd rather the document explain the model being used. Then SDOs will understand that this document does not apply to them since mostly they require that the Server interact with the attributes it receives and sends rather then just look stuff up in the database.
>
> The issue is *not* about "complex types", though that is the main
> point of contention. It's whether or not attribute design guidelines
> belong in the design guidelines document.
>
> Please explain in short, simple words why design guidelines do not
> belong in the design guidelines document. Don't mention "complex
> types". Don't mention "traditional" versus "modern" RADIUS model.
I cant to this because i never claimed that attribute design guidelines dont belong here. I perhaps said that if you dont want to fix the problems then just take the stuff out.
>
> The closest you've come to this is saying that text about the
> application layer doesn't belong in the document. That's a good
> argument, but there are arguments to counter it, too.
I didnt really say that either. I wanted you to add discussion on application layer and RADIUS layer. You didnt want to.
See, the document recogonizes that there is some application layer stuff happening on the client (NAS). It totally ignores that there are application layer stuff happening on the Server. That is the root problem in the document - for me.
There are other issues.
>
> 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/>