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

[Peter Deacon <[e-mail]>]

On Mon, 2 Sep 2013, Alan DeKok wrote:

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

To be clear the issue is not allocation of reserved fields it is M bit set 
where RFC6929 requires it not be.

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

Which vendors still use 241-246?

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

Allocation of reserved bits from RFC6929.

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

In this case lack of knowledge is NOT the problem.  The problem is proxies 
KNOWING something is WRONG and being expected to look the other way and 
forward the information on anyway.

regards,
Peter