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

[Alan DeKok <[e-mail]>]

Peter Deacon wrote:
> RFC5176 dynamic auth clients are not necessarily always RADIUS servers.
> We have production systems where CoA client and RADIUS server are
> separate with separate roles.  Seeing value in maintaining separation I
> do not favor Additional-Authorization.

  There is a network connecting the machines.  The RADIUS server can
proxy Access-Requests to the maching hosting the CoA information.

> Accounting proposal is not atomic and depends on assumptions about type
> of content.  (e.g long attribute not able to fit within 4096 byte limit
> cannot be transmitted)

  There has been no demonstrated need for large accounting packets.

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

  There are no deployed proxies which implement 6929.  The
implementations could support the "T" bit before this document is
finalized.  Nothing prevents implementations from adding new,
non-standardized functionality.

> General.
> 
> Attribute proxy not possible without proxy server modification to
> support draft.

  The only issue is the T bit.  No other proxy modifications are required.

> Existing proxy servers not supporting draft may lose ability to
> understand/enforce policy when attribute fragmentation is used.

  Tough.  Existing proxy servers which don't implement RFC 6929 won't
understand / enforce policies when RFC 6929 attributes are used.

  This argument is, IMHO, ridiculous.  If we are to believe it at face
value, it means we cannot implement ANY new feature in RADIUS.  Because
existing proxies won't be able to enforce policies for those new features.

  If you want to shut down all progress in RADEXT, just say so.  There's
no need to repeatedly bring up specious arguments.

> A policy of limiting large RADIUS UDP packets to MTU would about triple
> number of round trips needed to convey same information.

  Some systems don't support UDP fragmentation, and drop all fragmented
UDP packets.  So one alternative is to have *no* RADIUS traffic go
through the network.

  You may think that's better.  I don't.

  Alan DeKok.