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

[Peter Deacon <[e-mail]>]

On Mon, 2 Sep 2013, Alan DeKok wrote:

>> Proposed 'T' bit in extended long attributes means existing systems
>> supporting extended attributes may require enhancement to pass needed
>> data.  Despite 'SHOULD' language from RFC6929 I do not believe it
>> reasonable expectation proxy systems able to understand an attribute
>> known to be broke would elect to forward such an attribute anyway.

>  The draft authors had a conference call this morning about this, and
> other issues.

>  RFC 6929 Section 5.2 says:

>   This practice is NOT RECOMMENDED.  Proxy servers SHOULD forward
>   attributes, even attributes that they do not understand or that are
>   not in a local dictionary.  When forwarded, these attributes SHOULD
>   be sent verbatim, with no modifications or changes.  This requirement
>   includes "invalid attributes", as there may be some other system in
>   the network that understands them.

>  I believe that this text directly addresses the "T" bit, and the
> possibility of fragmenting attributes across multiple packets.  You say
> that it's not reasonable to expect a proxy to forward such an attribute.
> You haven't given any reason for that opinion.

Yep, it sure is what I was referring to by "'SHOULD' language".

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.

>  Until we have such discussion, we have real-world data from Eduroam,
> among other examples.  There have been real-world issues with proxies
> receiving attributes they don't understand, or think are malformed.
> Some proxies would then discard the packets or offending attributes.

>  This misbehavior caused real-world deployment problems.  The solution
> was to ensure that all proxies forwarded these attributes, even if they
> didn't understand them.

There are two issues which seem to be embedded in the above.

1. Forwarding of attributes you don't understand.

2. Incursions into standard space by vendor "A" and others.


Regarding #1

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.

Regarding #2

As far as I'm concerned this is ancient history, has been for years and
irrelevant in 2013.  Capitulating to an environment where nobody can be 
sure what an attribute even means is unacceptable.

Some attribute dictionaries have long memories and are quite easily 
changed.

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 do not support use of above as "cover" to justify incompatible 
retroactive changes.




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.

regards,
Peter