Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06

[Alan DeKok <[e-mail]>]

Peter Deacon wrote:
> Seems like a fairly common and obvious security 101 precaution in our
> (my) space you just don't forward what you know to be broke especially
> where it involves authentication/authorization parameters.  I see no
> reason at all to allow such behavior to take place.

  As I've said before, that attitude could prevent *any* new
functionality from being deployed.

  Some proxy implementations discarded any attributes which were not in
the local dictionary.  This idiocy isn't forbidden by the previous RFCs,
but is finally discouraged by 6929.  It prevents *any* changes to
RADIUS, which is madness.

> My opinion there certainly is value in administrative configuration
> allowing forwarding of unknown attributes.  I encourage all vendors to
> provide such an option to their customers.
> 
> Whether this is done or not seems to be orthogonal to the issue of
> rejecting a known attribute you know to be malformed.

  No.  A known attribute which uses fields that had previously been
marked "reserved".  And even if it is malformed, there are ways to deal
with it.

> Regarding #2
> 
> As far as I'm concerned this is ancient history, has been for years and
> irrelevant in 2013.

  No.  Vendors still ship equipment which poaches on the standard space.
 Deployments still rely on those attributes.  Eduroam was running into
issues with these attributes in the recent past.  With widely-used,
in-support commercial RADIUS servers.

> As with #1 the underlying issue seems to be orthogonal.  With this issue
> the conflict is invoked by systems not agreeing on attribute "type". In
> case of fragment draft "type" is not in question.  The problem here a
> type's format has been changed retroactively in an incompatible manner.

  I disagree, for reasons I've stated.

> My recommendation going forward is to find an alternative option which
> does not depend on incompatible M flag behavior.
> 
> One option in the definition of any long attributes to convey
> eduroam/SAML data specify how partial content should be handled and
> allocate new flags to effect inter-packet continuation without changing
> existing behavior.

  Where would those "new flags" exist?  In a new attribute format?

  Creating a brand-new incompatible standard isn't a solution to another
(allegedly) incompatible standard.

  For me, it's a simple principle.  Proxies have NO BUSINESS mucking
around with attributes they don't understand.  If the RADIUS packet is
well formed, the attributes (understood or not) should be sent onwards.

  Alan DeKok.