[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
I agree with Joe.
When one receives a string that one has to parse then it requires code change - or specific code to parse the string.
A complex attribute is no different then a string.
In fact code change is required anytime one has to process any attribute beyond simply transporting the message to the next hop. Whether it is at the client, the proxy or the server.
I dont understand ( i never understood) what is the objection around this!!!!
While i am at it --- what happened to getting rid of normative statements in this informative document????
On 21-12-2009, at 00:31 , Joseph Salowey (jsalowey) wrote:
>
>
>> -----Original Message-----
>> From: Alan DeKok [mailto:aland@deployingradius.com]
>> Sent: Friday, December 18, 2009 11:49 PM
>> To: Joseph Salowey (jsalowey)
>> Cc: Bernard Aboba; radiusext@ops.ietf.org
>> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
>>
>> Joseph Salowey (jsalowey) wrote:
>>> A. Section 2.1.3
>>>
>>> I did not find the discussion of complex attributes very compelling.
>>> Its not clear to me what the difference between string and complex
>>> attribute is. If your RADIUS server supports string then it seems
>>> that it would be possible to support a complex attribute without
>>> requiring a "code change".
>>
>> It depends on what you mean by "support".
>>
>> There is no question that a RADIUS server can *transport*
>> any complex attribute if the attribute is treated as type
>> "string". However, having the RADIUS server parse that
>> attribute requires much more work.
>>
> [Joe] It seems a type "string" attribute would have the same parsing
> requirement.
>
>> Perhaps a better argument is to ask "why?". i.e. Why is a
>> data structure being sent when the contents could have been
>> broken out into separate attributes with standard data types?
>>
> [Joe] To me it seems like you are just pushing the problem around. If
> the RADIUS server doesn't have to validate or parse the attribute then
> it doesn't make a difference. If the RADIUS server does need to process
> it then you need code to do the validation and parsing across several
> basic attributes.
>
>> The document tries to suggest that where possible, complex
>> attributes should be replaced by attributes with standard
>> data types. Where that is not possible, complex attributes
>> could be used.
>>
>>> B. Section 2.1.4
>>>
>>> I'm not really sure what this section is trying to accomplish. It
>>> seems to be a lot about deployment guidelines instead of
>> design guidelines.
>>> I'm also not convinced that the use of complex attributes
>> makes things
>>> less secure. It does not seem this section belongs in this
>> document.
>>
>> Using complex attributes does not make things less secure. *Code
>> changes* make things less secure.
>>
> [Joe] Complex attributes don't always require code changes and if you
> are adding several new basic attributes that need to be validated
> together then you need code to do that.
>
>> The intent of this section is to explain some of the
>> reasons behind the recommendations, rather than to have them
>> appear out of thin air.
>>
>>> C. Section 5
>>>
>>> This section references section 2.1.4, however it does not
>> seem there
>>> is anything actionable for a protocol document to do with
>> section 2.1.4.
>>
>> I think the reference should be to 2.1.3.
>>
> [Joe] OK, I think that makes more sense.
>
>>> D. Section A.2.2
>>>
>>> Since I did not agree with the motivation for section
>> 2.1.3, I don't
>>> find this section compelling.
>>
>> This is one point where I strongly disagree. It can be
>> summarized as "keep things simple".
>>
>> Would you counter this section by suggesting it's a *good*
>> idea to have complex attributes, where standard ones would do
>> just as well? If so, why?
>>
> [Joe] That does not seem to be what section A.2.2 states. It talks
> about whether attributes need dynamic computation or not. It seems the
> second and third bullet outlaw all cases, since the first covers dynamic
> computation and the second covers static attributes.
>
>>> E. Section A.2.1
>>>
>>> I don't see how defining a polymorphic attribute as multiple
>>> attributes helps. I'm probably missing something, do you
>> have an example?
>>
>> See Section 3.2 for a larger explanation. In short:
>>
>> - Attribute X means "integer", unless there is another
>> attribute Y in the packet, in which case Attribute X means
>> "mac address"
>>
>> Both the size and contents of the attribute changes.
>> There's really no good reason. Instead, two standard
>> attributes can be used, with no magical meanings.
>>
> [Joe] OK, got it.
>
>> 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/>