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

["David B. Nelson" <d.b.nelson@comcast.net>]

Jari Arkko writes...

> > I've always thought 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).

This "fix" would partially address the issue, and would be of the form of an
implementation suggestion.  It would not affect the on-the-wire protocol.
There may still be cases where an operator desires strict policy but needs
NAS capability signaling.  This text would not address that case, but as you
say, may address a sufficient number of cases to be worthy of adding to the
document.  I recommend that we consider adding it.




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