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

Hi,

I plan to attend the meeting, and I am rather sure that at least another co-author will be there, so please do add the item to the agenda.

Be goode,

On 16 Oct 2013, at 09:00 , Alejandro Perez Mendez wrote:

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" <jouni.nospam@gmail.com><mailto:jouni.nospam@gmail.com> 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 <jouni.nospam@gmail.com><mailto:jouni.nospam@gmail.com> 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
radext@ietf.org<mailto:radext@ietf.org>
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org<mailto:radext@ietf.org>
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org<mailto:radext@ietf.org>
https://www.ietf.org/mailman/listinfo/radext

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx