Re: DISCUSS and COMMENT: draft-ietf-radext-fixes

[Jari Arkko <jari.arkko@piuha.net>]

Dave,

> Capability signaling is an issue that has been addressed in an ad-hoc
> fashion for a couple of recent extensions (e.g. GEOPRIV).  We've discussed
> it in more general terms, but never had consensus to take action.
>   

Reading on...

> I've always though that it would be a good practice for a RADIUS client
> implementation to have a configuration parameter to control this behavior,
> allowing the system administrator to opt for maximum plug-'n'-play behavior
> (ignore unknown attributes) or to opt for maximum security (deny service
> when presented with unknown, non-VSA attributes in an Access-Accept).  I
> don't think there is one policy that will work appropriately in all
> deployment scenarios.
>   

I think the above makes a lot of sense. I would feel much more
confident that we are doing the right thing if the document
said clients should have a configuration knob for this (and then
the default value of the knob could be what the document
currently states).

(Note: this part of my Discuss is not intended to overwrite strong
consensus in the WG, if one exists -- I mainly wanted to know
that you are aware what you are doing.)

>>   Administrators are generally aware of the need to fight with
>> implementations to get client and server to agree on a set of attributes
>> that they both accept.
>>     
>
> That's what happens in the absence of capability signaling or a global
> strict/lax policy configuration feature.
>   

Right -- can we improve on this somehow? I think giving the
admins a tool (the knob) to deal with this would be useful.

Jari


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