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

[Peter Deacon <[e-mail]>]

On Fri, 9 Aug 2013, Jouni Korhonen wrote:

> Based on the discussion in Berlin we are ready to start another
> adoption call for the solution for fragmentation of RADIUS packets.

I would support this draft with narrower scope as interim solution 
addressing a specific use.

Have some concerns with draft as a general solution:

Section 2.

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.

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)

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.

General.

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

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

Section 5.

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

Section 10.

Message-Authenticator does not offer replay protection.  Recommend text 
"This signature prevents forging to the limits of the existing security."

regards,
Peter