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

[Peter Deacon <[e-mail]>]

On Thu, 22 Aug 2013, Alan DeKok 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.

Speaking for myself this is problematic.  Dynamic auth clients are just 
clients with no capability to act as RADIUS server.  They only manage a 
subset of possible authorization parameters not capable of full response.

The argument is not whether it is possible to coordinate rather value in 
maintaining separation.  If transport limits are lifted rather than 
supporting adoption of this draft none of these "workarounds" are 
necessary.

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

If authors see no value recommend removing associated references from 
draft.

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

Incorrect

> implementations could support the "T" bit before this document is
> finalized.  Nothing prevents implementations from adding new,
> non-standardized functionality.

If modification is necessary I see no value in supporting this draft vs 
solutions addressing underlying transport limit.  The whole point was that 
it work with existing systems unmodified.

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

I apologize for any confusion.  By attribute proxy I mean forwarding 
requests based on attributes other than User-Name.

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

My understanding is both existing and new attributes may be conveyed using 
the fragmentation mechanism.  Existing attributes may end up being 
transmitted in separate requests where previously they would have to occur 
in the same request.

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

This is an edge problem within most operators administrative control to 
effect.

regards,
Peter