Subject: Re: [radext] New Draft for RADIUS Message Bundling

From: <[email-masked]>
Date: Sun, 6 Sep 2015 20:18:07 +0530

Dell - Internal Use - Confidential
Hi Sam,

Thanks a lot again for your comments. Sorry for the delay in replying back to your mail.

Yes, agree with you. In case of TCP, we can stick multiple RADIUS messages in a single message and they can be processed without any change on Server Side. The concept of bundling may not be required here.

In case of UDP, the same may not be done and may need standardization since currently, each RADIUS Message is assumed to hold only one RADIUS request.

Thanks a lot again for your valuable review comments ☺.

Thanks,
S. Aravind Prasad

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Thursday, August 20, 2015 3:35 PM
To: Sridharan, Aravind
Cc: [email-masked]; [email-masked]; Sivarama, Sanal Kumar; [email-masked]
Subject: Re: [radext] New Draft for RADIUS Message Bundling

>>>>> writes:

> Hi Sam, Thanks a lot again for your review comments.

> Yes, agree with you. Finally it comes down to the following:

> 1) Without bundling (in case of individual packets), there is
> the overhead of adding TCP and Ethernet headers to individual
> RADIUS packets sent to server.

> 2) With Bundling, the overhead of TCP and Ethernet Header
> additions are avoided. Instead, now it€™s the overhead
> of bookkeeping and bundling multiple RADIUS requests in the single
> message.

Except that even without bundling TCP will stick more than one RADIUS message in a single packet.
Let's say that your radius messages are 150 bytes or so, and you can get
9 of them into a TCP packet.
So, the TCP and ethernet headers are amortized over 9 messages without your proposal.

Let's say that you somehow save enough space that you can get a 10th request into the packet. That would be doing fairly good in my opinion for your proposal. Even if you could do that well, I don't understand how it's worth standardizing.

It seems like you get a vast majority of the benefits simply from putting more than one RADIUS message into a single TCP packet, and we get that today.

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 6 Sep 2015 15:07:14 +0000 (UTC)

Aravind Sridharan writes...

> In case of TCP, we can stick multiple RADIUS messages in
> a single message and they can be processed without any change
> on Server Side. The concept of bundling may not be required here.
> 
> In case of UDP, the same may not be done and may need standardization
> since currently, each RADIUS Message is assumed to hold only one 
> RADIUS request.

Since the proposal described here will require client and server implementation changes in order to interoperate, why shouldn't the recommendation be "just use TCP"?

Seriously.  I often think we suffer from standardizing too many different solution approaches to any given problem.  Diversity is good, up to a point.  Past that point, it dilutes the advantages of having standards.

Regards,

Dave Nelson

---

From: Alan DeKok <[email-masked]>
Date: Sun, 6 Sep 2015 11:29:00 -0400

> Yes, agree with you. In case of TCP, we can stick multiple RADIUS messages in a single message and they can be processed without any change on Server Side. The concept of bundling may not be requir…

  It is not required.  It is *harmful* for TCP.

> In case of UDP, the same may not be done and may need standardization since currently, each RADIUS Message is assumed to hold only one RADIUS request.

  For UDP, there's a much simpler solution.  Allow multiple RADIUS packets in one UDP packet.  RFC 2865 Section 3 says this about the Length field of the RADIUS packets:

      The Length field is two octets.  It indicates the length of the
      packet including the Code, Identifier, Length, Authenticator and
      Attribute fields.  Octets outside the range of the Length field
      MUST be treated as padding and ignored on reception.  If the
      packet is shorter than the Length field indicates, it MUST be
      silently discarded.  The minimum length is 20 and maximum length
      is 4096.

  It is possible instead to say "octets outside of the Length field can be treated as a subsequent RADIUS packet inside of the same UDP packet".

  i.e. a UDP packet with a 40 byte payload can carry two 20-byte RADIUS packets.

  That solution is better than packing RADIUS inside of RADIUS.  But both solutions have a very small chance of getting accepted by the WG, and an even smaller chance of passing IETF transport area review.

  TCP is the better solution.

  Alan DeKok.

---

From: "Satyanarayana Danda (sdanda)" <[email-masked]>
Date: Mon, 7 Sep 2015 05:05:54 +0000

In fact, to have this kind of possible extensions for better performance
and scale, we tried to bring a frame work a couple of years back.
To avoid, interoperability issues, you can refer the following.

http://tools.ietf.org/html/draft-halwasia-radext-capability-negotiation-00

Thank you,
Satya

On 06/09/15 8:59 pm, "Alan DeKok" <[email-masked]> wrote:

>> Yes, agree with you. In case of TCP, we can stick multiple RADIUS
>>messages in a single message and they can be processed without any
>>change on Server Side. The concept of bundling may not be required here.
>
>>since currently, each RADIUS Message is assumed to hold only one RADIUS
>>request.
>
>  For UDP, there's a much simpler solution.  Allow multiple RADIUS
>packets in one UDP packet.  RFC 2865 Section 3 says this about the Length
>field of the RADIUS packets:
>
>  It is possible instead to say "octets outside of the Length field can
>be treated as a subsequent RADIUS packet inside of the same UDP packet".
>
>  That solution is better than packing RADIUS inside of RADIUS.  But both
>solutions have a very small chance of getting accepted by the WG, and an
>even smaller chance of passing IETF transport area review.
>
>_______________________________________________
>radext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/radext

---

From: <[email-masked]>
Date: Mon, 7 Sep 2015 15:58:21 +0000

Hi,
(as individual)

having or defining a new RADIUS capability negotiation mechanism will not make acceptable a new extension that might not be needed at all :)

I still don't see why using TCP would not be the recommendation for the issue described in the draft, according that the proposed solution over UDP in the draft implies anyway upgrades of client and server. So if an upgrade is anyhow needed, moving from UDP to TCP seems to be more appropriate than defining a new extension that would provide the same functionality but over UDP. 

Lionel

-----Message d'origine-----
De : radext [mailto:[email-masked]] De la part de Satyanarayana Danda (sdanda)
Envoyé : lundi 7 septembre 2015 07:06
À : [email-masked]
Cc : [email-masked]; [email-masked]; Alan DeKok; [email-masked]; [email-masked]
Objet : Re: [radext] New Draft for RADIUS Message Bundling

In fact, to have this kind of possible extensions for better performance and scale, we tried to bring a frame work a couple of years back.
To avoid, interoperability issues, you can refer the following.

Thank you,
Satya

On 06/09/15 8:59 pm, "Alan DeKok" <[email-masked]> wrote:

>packets in one UDP packet.  RFC 2865 Section 3 says this about the 
>Length field of the RADIUS packets:
>
>  That solution is better than packing RADIUS inside of RADIUS.  But 
>both solutions have a very small chance of getting accepted by the WG, 
>and an even smaller chance of passing IETF transport area review.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 7 Sep 2015 12:00:29 -0400

> I still don't see why using TCP would not be the recommendation for the issue described in the draft, according that the proposed solution over UDP in the draft implies anyway upgrades of client an…

  I agree.

  The only problem with TCP is the 8 bit limit on RADIUS IDs.  So TCP connections are limited to 256 outstanding packets.  That makes it difficult to fill a local link with RADIUS packets.

  The solution would be to extend the RADIUS ID space.  There's at least one commercial vendor doing this for their servers.  So the solution works.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Sep 2015 11:27:47 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> On Sep 7, 2015, at 11:58 AM, <[email-masked]>
    Alan> <[email-masked]> wrote:
    >> I still don't see why using TCP would not be the recommendation
    >> for the issue described in the draft, according that the proposed
    >> solution over UDP in the draft implies anyway upgrades of client
    >> and server. So if an upgrade is anyhow needed, moving from UDP to
    >> TCP seems to be more appropriate than defining a new extension
    >> that would provide the same functionality but over UDP.

    Alan>   I agree.

I agree as well.
I've asked multiple time to try and understand the use case for this
proposal.
So far I have not seen anything that would justify standardizing a
solution on this.
I do not plan to spend more effort on this discussion unless I see folks
who have an established track record in the working group arguing in
favor of doing work here.

--Sam