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

From: Jouni Korhonen <[email-masked]>
Date: Mon, 7 Oct 2013 08:45:19 +0300

Sam,

Sorry for the delay. Inline..

On Sep 4, 2013, at 1:48 AM, Sam Hartman <[email-masked]> wrote:

>>>>>> "Jouni" == Jouni Korhonen <[email-masked]> writes:
> 
>    Jouni> Folks,
> 
>    Jouni> We will take draft-perez-radext-radius-fragmentation-06 as
>    Jouni> the _basis_ for the WG solution
> 
> Hi.
> I'd be happy if you reword that sentence as "_a_ _basis_ for _a_ WG
> solution."

Pardon my non-native English.. 'a' is fine.

> 
> I think there was significant support for the idea that this draft alone
> is insufficient and that we want to revisit the RADIUS message size over
> TCP.
> I do not believe the discussion supports the idea that this draft will
> be a singular solution.
> So, I'd ask the chairs to clarify.

In the mail you quoted I also said:

"agrees with. whether we need further documents on fragmentation, e.g. as
a generic long term solution is to be seen and discussed."

which should be clear answer for what you ask above. We can revisit the
fragmentation topic if the current WG I-D does not fit in all use cases
and there can be further documents. Whether we would need to recharter
for more documents on fragmentation or whether just new milestones are
sufficient, I have not thought about yet.

- Jouni

> --Sam

---

From: "Sanchez, Mauricio" <[email-masked]>
Date: Wed, 16 Oct 2013 06:01:58 +0000

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 

On 8/26/13 12:35 AM, "Jouni Korhonen" <[email-masked]> 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 <[email-masked]> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/radext

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 16 Oct 2013 09:00:52 +0200

> As a reminder, we are on the 1st day (Monday) at 1300.

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 17 Oct 2013 16:49:27 +0000

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:

-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" <[email-masked]><mailto:[email-masked]> wrote:

Folks,

- Jouni & Mauricio

On Aug 9, 2013, at 3:02 PM, Jouni Korhonen <[email-masked]><mailto:[email-masked]> wrote:

Folks,

- Jouni & Mauricio

_______________________________________________
radext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]
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