Re: [Technical Errata Reported] RFC5176 (2012)

[Avi Lior <avi@bridgewatersystems.com>]

On 26-01-2010, at 23:15 , David B. Nelson wrote:

> On Jan 26, 2010, at 9:33 AM, Avi Lior wrote:
> 
>> -It would have been useful to allow VSA to be included in Access- 
>> Reject.
>> So at least an SDO can return an Error-Cause of their own or even
>> Authorization-Failure-Cause or Authentication-Failure-Cause instead of
>> hacking the Reply-Message attribute.
> 
> Potentially useful, yes, but also "dangerous".  If VSAs are allowed in  
> Access-Reject messages, it becomes much harder to maintain the "no  
> means no" doctrine.


If someone wanted to break the doctrine they can just hack Reply-Message or they can just use a VSA anyway.  You cant prevent anything if someone want to be dangerous or careless or whatever you want to call it.

If you want someone to be respectful of your protocol then you should create a protocol that demands respect by providing the tools necessary to meet the legitimate  usecases for which that protocol will be used.  Overtime those usecases will change.  Failing to recognize those changes means that people will fix it themselves and you wil loose control of the protocol.  This is exactly where we were heading before RADEXT was formed.  But the IETF was smart enough to recongize that the use of the RADIUS protocol is strong and is evolving.

So I would assert that telling a NAS why we are sending an Access-Reject is a valid use-case - after all Diameter allows the Server to specifically indicate when Authorization has failed (vs Authentication).

BTW I think what is also missing is how one translates between Diameter Result-Code and Error-Cause.


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