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

[Alan DeKok <[e-mail]>]

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

  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.

  In conclusion, I believe we're safe in adding the "T" bit in the
fragmentation draft.  Implementations compliant with 6929 will ignore
the "T" bit, but SHOULD still forward the attributes they believe are
malformed (when the T bit is set)

  If you're saying that your implementation discards these attributes, I
would suggest that your implementation is incompatible with new
standards, and existing deployments.

  Alan DeKok.