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

Hello Peter,

thanks for the comments. See some responses below.

El 21/08/13 20:05, Peter Deacon escribió:
> 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)

I probably misunderstood your comment. We do not deal with CoA or 
Accounting exchanges. They are left the way they are.

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

umm, you are probably right. Let's see what Alan says about this.

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

According to your previous comment, that would be partially true, but 
only when the proxy supports RFC6929.

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

That's probably right. You are able to send the data, but you have to 
pay a price. Compromise is the key here.

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

Thanks, we will update the text accordingly.

Regards,
Alejandro
>
> regards,
> Peter
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext