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

[Alejandro Perez Mendez <[e-mail]>]

El 16/10/13 08:01, Sanchez, Mauricio escribió:
> Now that the the Perez, et.al. draft has made it into WG draft status we
> see that discussion turned to what the scope of solution should be.  Can
> the authors of the draft summarize their current understanding of the
> situation and what their suggested/planned next steps are?  I expect that
> one or more of the authors will be at IETF 88 to add this draft to the
> agenda, so please confirm availability.
>
> As a reminder, we are on the 1st day (Monday) at 1300.
>
> -Mauricio & Jouni

Dear Mauricio & Jouni,

the scope of this draft is to provide a means for the transmission of 
large amounts of authorization data between two RADIUS endpoints. The 
reasons why it is focused only on authorization data are described in 
the "Scope of this document" section on the draft, and can be summarized 
on the following sentence: "Other exchanges (i.e. authentication and 
accounting) do not require of such a mechanism". This is justified on 
the following premises:

1) Authentication exchanges already deal with fragmentation (e.g. 
RADIUS-EAP). Moreover, as they represent the most critical part of a 
RADIUS conversation, it is preferable to not introduce any modification 
to their operation that may affect existing equipment.
2) There not documented need for fragmentation of accounting data so far.

Additionally, other of the cornerstone points of this mechanism is to 
work through unmodified proxies, thus:
* It should be based on UDP
* It should not require of any change to the RADIUS specification
* It should conform with current RADIUS attribute & packet formats

Those are the basis of our draft, and the requirements that have guided 
the definition of the current fragmentation mechanism.

However, it does not provide a perfect solution. In particular, it 
requires proxying to be done based on the User-Name attribute (although 
the most typical case, specific scenarios may have a different 
configuration), it requires proxies to not drop unrecognised attributes 
(who does not?), it requires proxies to not try to modify the contents 
of a packet (apart of inserting Proxy-State attributes), and the 
receptor do not know how much data will arrive until it  actually 
receives it.

Taking into account aforementioned restrictions it seems that, for new 
deployments where keeping the infrastructure unmodified is not a MUST, a 
different approach of using RADIUS TCP, *and* changing RADIUS 
specification to increase the maximum packet length from 4 KiB to 64 KiB 
may provide a simpler solution.

 From my perspective, both solutions could coexists. While the TCP-based 
solution may provide a simpler solution, in scenarios where existing 
infrastructure cannot be easily upgraded, an UDP-based solution is still 
needed.

We are currently finishing a new version which clarifies some points 
that were raised on the mailing list, mainly related to the mentioned 
limitations. It is our intention to have it ready before the IETF meeting.

I will not personally attend the meeting, but I will be available via 
Jabber.

Regards,
Alejandro


>
>
>
>
>
> On 8/26/13 12:35 AM, "Jouni Korhonen" <[e-mail]> wrote:
>
>> Folks,
>>
>> We got some support and none going against the adoption. There were
>> already some very detailed discussion on aspects people want to see
>> changed in the document, which is a really good start.
>>
>> We will take draft-perez-radext-radius-fragmentation-06 as the _basis_
>> for the WG solution. Now the WG needs to come up with text that everybody
>> agrees with. whether we need further documents on fragmentation, e.g. as
>> a generic long term solution is to be seen and discussed.
>>
>> - Jouni & Mauricio
>>
>>
>> On Aug 9, 2013, at 3:02 PM, Jouni Korhonen <[e-mail]> wrote:
>>
>>> Folks,
>>>
>>> Based on the discussion in Berlin we are ready to start another
>>> adoption call for the solution for fragmentation of RADIUS packets.
>>>
>>> This email starts a two week consensus call on adopting:
>>>
>>> Filename:         draft-perez-radext-radius-fragmentation
>>> Revision:         06
>>> Title:            Support of fragmentation of RADIUS packets
>>> Creation date:    2013-07-02
>>>
>>> Express your concerns or support by 23rd August EOB on the mailing list.
>>>
>>> - Jouni & Mauricio
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext
>>
>>
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext